Sign In
    Wisconsin Lawyer
    February 07, 2008

    Thinking Outside the "Business Records" Box: Evidentiary Foundations for Computer Records

    The foundation for introducing computer-generated records into evidence is different than that for the familiar business records exception, but it is not necessarily more difficult. Read how the process works, establishes authenticity, and produces reliable results.

    Timothy M. O'Shea


    The "sniffer" log in the Rock County hacker case had me stumped. I could not use the business record evidentiary foundation to get the log admitted at trial, because the log was created in response to a series of computer attacks and not as part of day-to-day regularly conducted activity. Without the log, however, my prosecution case wasn't going anywhere. As described below, my resolution of the evidentiary problems in this case gave me a clearer understanding of how to lay sturdy, accurate foundations for the admission of computer-generated records.

    This article addresses the foundation for records - like the sniffer log - that are created in whole or part by a process rather than a person. This category of records is much broader than most litigators appreciate: for example, bank records, telephone records, and even many business transaction records are created at least partly by a computer process. Here is a commonplace example of a record created by a process rather than a person: the cash register's computer, not the grocery store clerk, totals your purchases, figures the tax, and prints the time and date on your receipt. As explained below, records created by a process do not implicate the hearsay rules at all. Rather, laying the evidentiary foundation for such records requires a description of the reliability of the process. A comprehensive foundation checklist for computer-generated records accompanies this article. Although this case was prosecuted in federal court, the evidentiary points contained in this article apply to both the Wisconsin and the federal systems.

    The Rock County Hacking Case

    The hacker had worked in the computer support department for a large Rock County, Wis., parts distributor. The hacker was fired after his bosses figured out that he was the source for the serious computer malfunctions that only occurred when he went home for lunch. The hacker's bosses likened him to a firefighter who torches buildings to increase his chances for heroism, because the hacker would return from home and immediately fix the knotty and seemingly inexplicable computer glitches that had stumped his colleagues.

    By 9:30 on the morning that the hacker was fired, corporate security guards had escorted the newly-unemployed hacker, cardboard box of personal effects in hand, to his car. Simultaneously, the computer support supervisors disabled the hacker's computer system passwords. In less than an hour, however, the hacker was back in his ex-employer's computer system. Over the next 10 days, the hacker used his former colleagues' passwords to repeatedly hack his ex-employer's computer system: intercepting email, deleting critical databases, and turning off the virus protection system.

    To identify the intruder, one of the hacker's former colleagues installed a sniffer program to monitor traffic through a certain system port - a computer communication channel - that the hacker had used to mount his attacks. The sniffer program created a log - analogous to a surveillance video - to record activity through the port. It worked. The hacker returned to the same port to resume his attacks against his former employer's computer system. The sniffer program recorded the hacker's commands to the computer system and the computer's automatic responses to those commands. The sniffer program also captured the hacker's Internet Protocol address. The address information showed that the hacker was using an Internet connection associated with the hacker's home. A search warrant executed at the hacker's home resulted in the recovery of a networked computer system. After a careful analysis by computer forensic experts at the Wisconsin Department of Justice (DOJ), the hacker was indicted in federal court and his case was set for trial. Confronted by the discovery of damning evidence that the hacker had hidden in a "virtual machine" - in this context, a file hiding a separate operating system with associated programs - within his computer, the hacker pleaded guilty on the eve of trial. The district court sentenced the hacker to federal prison and ordered him to pay full restitution.

    In addition to the evidentiary aspects, three practical considerations concerning this case should be noted by lawyers who advise business clients. First, by calling law enforcement, the parts distributor was able to specifically deter the hacker - at a minimum, during his prison and supervision terms. Second, the local police and the Wisconsin DOJ forensic experts proved effective during the investigation, the computer seizure, and the analysis. Third, all press releases in the case were issued after consulting with the parts distributor's corporate counsel. These factors resulted in the business being accurately portrayed as a good corporate citizen and in accountability for the hacker.

    The Foundation Used for Computer Records

    Many courts have categorically determined that computer records are admissible under the hearsay exception for records of regularly conducted activity - more commonly known as the business records exception - without first asking whether the records are hearsay.1 This view, however, is changing as litigants and courts better understand how different types of computer data are created. As explained below, computer-generated records are not hearsay at all. As a result, the familiar business records foundation is an inadequate basis for introducing these records.2 True business records within the hearsay exception are records made reasonably close in time to the recorded event, by a person with knowledge of the regularly conducted business activity, so long as it was regular practice of the business to make that report.3 Thinking of computer-generated records as hearsay starts a person off on the wrong foot. Such records are not created by a person, but by a computer process, and so are not hearsay at all.

    Three Categories of Computer Records

    Three types of records are stored in computers: 1) those that record assertions of persons (hearsay); 2) records resulting from a process (nonhearsay); and 3) records that are mixed or partially hearsay. Examples follow.

    Hearsay. These are records in computer storage that contain assertions, such as a personal letter, a memo, accounting records, and records of business transactions input by persons (for example, hotel or airline reservations taken over the telephone).

    Nonhearsay. These are records created by a process that does not involve a human assertion, such as telephone toll records, cell tower information, global positioning system (GPS) data, automated teller machine (ATM) and electronic banking records, Google search logs, and log-in records from an internet service provider (ISP) or Internet newsgroup. Although human input - dialing a phone number or punching in a PIN - triggers some of these processes this conduct, as explained below, is a command to a system, not an assertion.

    Mixed Hearsay and Nonhearsay. These records are a combination of the first two categories, such as email containing both content and header information; documents in which the dates of file creation, last modification, and last access are important; chat room logs; and spreadsheets with figures that have been typed in by a person, but the columns of which are automatically totaled by the computer program.

    The three categories require different evidentiary foundations. When sorting out the foundational requirements, the first question is whether the record, in whole or in part, implicates the hearsay rules.

    The Hearsay Rule

    Wis. Stat. section 908.01 provides that "`[h]earsay' is a statement, other than one made by the declarant while testifying at the trial or hearing, offered in evidence to prove the truth of the matter asserted."4 A "`statement' is (a) an oral or written assertion or (b) nonverbal conduct of a person, if it is intended by the person as an assertion."5 The main point here is that the hearsay rules apply to statements made by persons, not machines.

    Timothy M. O'SheaTimothy M. O'Shea, U.W. 1991, has been a prosecutor in the U.S. Attorney's Office in Madison since 1991. He has been the designated Western District of Wisconsin computer crime prosecutor since 1995 and has been senior litigation counsel for the office since 2002. O'Shea's views do not necessarily reflect the official position of the U.S. Department of Justice.

    The Wisconsin Rules of Evidence do not define assertion. However, the Wisconsin Court of Appeals has held that "an `assertion' as used in Wis. Stat. § 908.01(1) means an expression of a fact, condition, or opinion."6 Hearsay is considered unreliable for three reasons: 1) By definition, hearsay statements cannot be effectively cross-examined to test perception, memory, bias, character, and so on. 2) Hearsay statements are not made under oath. 3) The trier of fact - the judge or the jury - cannot observe the declarant's demeanor to determine credibility.

    Nonhearsay records, the second category of records described above, do not record human statements but instead are the result of a program designed to process information.7 Thus, these records are not hearsay because either there is no person involved8 (for example, GPS tracking) or the human conduct is nonassertive (dialing a phone number or punching in a PIN at an ATM).9 As a result, the foundational issues do not relate to hearsay concerns - whether the declarant was truthful, biased, or has lousy eyesight or other perception problems - but instead to whether the computer equipment and software were functioning properly.10 These are questions of "authentication" under Wis. Stat. section 909.01. For readers who practice criminal law, it is worth noting that since such records are not statements of persons, the confrontation clause, and by extension Crawford v. Washington, are not implicated.11

    If the Business Records Exception Ain't Broke, Why Fix It?

    Since the second category of records listed above - those created without a human assertion - are not hearsay, use of the business records foundation is incorrect and inadequate. When litigants have been successful, however, introducing phone records, computer-generated receipts, cell tower data, and other computer-generated records by employing the tried, true, and simple business records foundation, they may be reluctant to conduct more accurate but also more probing inquiries into the reliability of the computer and programs.

    However, as attorneys and courts learn more about computers and computer records, they will reasonably question whether particular computer records are hearsay and whether those records should be admitted solely under the business records exception. Moreover, even records falling under the business records exception are subject to challenge if the circumstances "indicate lack of trustworthiness."12 Litigants should expect that as courts learn more about computers and computer records, they will require foundations that demonstrate the reliability of the computer and the programs that created the records.13 Besides the obvious benefit of getting the records into evidence, a more informed foundation explaining what the computer or program does likely will help the finder of fact to better understand the soundness and relevance of the records.

    Records in the third category described above - records that combine hearsay and nonhearsay - require that the proponent lay a foundation that establishes both the admissibility of the hearsay statement and the authenticity of the computer-generated record.

    Foundational Checklist

    The accompanying checklist is for records that are created by a process. Admissibility of evidence is always conditioned on a showing that the matter is what the proponent claims it to be.14 To demonstrate authenticity for process-generated records, the rule requires one to introduce "[e]vidence describing a process or a system used to produce a result and showing that the process or system produces an accurate result."15

    How much detail the proponent should provide depends on the complexity or familiarity of the record at hand. For example, a grocery store receipt, a bank statement, or a phone bill likely will require a very simple foundation, while more explanation likely would be needed for a log showing a hacker attack or cell phone tower data that gives information about the route a cell phone user took between cities. While the foundations for many computer-generated records will not require the proponent to cover each point noted in the checklist, the goal is for the checklist to be comprehensive.16

    The concern with a comprehensive checklist is that the reader might be left with the incorrect impression that it will be very difficult to get computer-generated evidence admitted at trial. That is wrong for three reasons. First, as noted above, although the checklist is comprehensive, most electronic evidence will not require a litigant to explore every point. As with other issues of authenticity, a litigant need only produce sufficient evidence to support a finding that the evidence is what its proponent claims it is.17 After meeting this threshold, opposing arguments go to the weight, not the admissibility, of the evidence.18 Second, a challenge to authenticity of the computer-generated evidence must be based on specific concerns - mere speculation and unsupported theories will not preclude admission.19 Third, to establish the authenticity of the evidence, it often will suffice to have a lay witness testify to his or her familiarity with the computer process that produced the record and its reliability.20 One need not call a computer expert every time one wants to introduce computer-related evidence.

    The checklist for computer-generated records is intended to show the reliability of the process and by extension, reliability of the information that the litigant hopes to introduce in evidence.


    There is a clear conceptual overlap between the authenticity of the computer-generated information and the trustworthiness of business records produced by persons. The point with both is to show that the process employed works and produces a trustworthy result. Litigants likely will be reluctant to move away from the comfortable and familiar business records foundation. However, thoughtful analysis of the computer-generated records, and the questions necessary for admission, will show that the evidentiary foundation for introducing those computer-generated records will be different than that for the business records exception, but in the end, not necessarily more difficult.


    1United States v. Moore, 240 Fed. Appx. 699, 2007 WL 1991060, at *8 (6th Cir. 2007) (holding telephone records, and other computer data compilations, are admissible under business records exception); United States v. Fujii, 301 F.3d 535, 539 (7th Cir. 2002) ("Computer data compiled and presented in computer printouts prepared specifically for trial is admissible under Rule 803(6) [the business records exception]."); United States v. Briscoe, 896 F.2d 1476, 1494 (7th Cir. 1990) ("computer data compilations are admissible as business records").

    2See Orin S. Kerr, Computer Records and the Federal Rules of Evidence, USA Bulletin, Mar. 2001; Adam Wolfson, "Electronic Fingerprints": Doing Away with the Conception of Computer-Generated Records as Hearsay, 104 Mich. L. Rev. 151 (2005).

    3Wis. Stat. § 908.03(6).

    4Wis. Stat. § 908.01(3) (emphasis added).

    5Wis. Stat. § 908.01(1) (emphasis added).

    6State v. Kutz, 2003 WI App 205, 267 Wis. 2d 531, 560, 671 N.W.2d 660; cf. United States v. Lewis, 902 F.2d 1176, 1179 (5th Cir. 1990) ("[T]he term [assertion] has the connotation of a positive declaration.").

    7United States v. Washington, 498 F.3d 225, 231, (4th Cir. Aug. 22, 2007) ("Only a person may be a declarant and make a statement"); cf. State v. Zivcic, 229 Wis. 2d 119, 131, 598 N.W.2d 565 (Ct. App. 1999) (holding Intoxilyzer printout is not person's statement but instead is the result of a process and accordingly is not hearsay).

    8See United States v. Hamilton, 413 F.3d 1138, 1142-43 (10th Cir. 2005) (holding computer-generated header information associated with uploaded child pornography images was not hearsay, as "there was neither a `statement' nor a `declarant' involved here within the meaning of" the hearsay definition) (citing United States v. Kohorozian, 333 F.3d 498, 506 (3d Cir. 2003) ("nothing `said' by a machine ... is hearsay.")).

    9Entering a phone number or PIN is a command to a system (that is, connect me to the phone with this number or access my bank records) and is thus nonassertive conduct. See Kutz, 267 Wis. 2d at 564 (holding commands that do not contain an expression of fact, condition, or opinion are not hearsay); United States v. Bellomo, 176 F.3d 580, 586 (2d Cir. 1999) ("Statements offered as evidence of commands or threats or rules directed to the witness, rather than for the truth of the matter asserted therein, are not hearsay."); People v. Reyes, 62 Cal. App. 3d 53, 67 (1976) ("words of direction or authorization do not constitute hearsay since they are not offered to prove the truth of any matter asserted by such words").

    10See State v. Colwell, No. 05-0280, 2006 WL 468732 (Iowa Ct. App. March 1, 2006) (holding telephone toll records, produced by a computer process, lack a human declarant and are thus not hearsay; the admissibility of such records is "determined on the basis of the reliability and accuracy of the process involved."); see also Hawkins v. Cavalli, 2006 WL 2724145 (N.D. Cal. 2006) (holding file access dates result from a computer's internal operations and are thus not hearsay).

    11United States v. Washington, 498 F.3d 225 (4th Cir. 2007) (holding machine's output was not a statement of a person and thus did not implicate prohibition of "testimonial hearsay" announced in Crawford v. Washington, 541 U.S. 36 (2004)).

    12Wis. Stat. § 908.03(6).

    13See, e.g., Hamilton, 413 F.3d at 1142-43.

    14Wis. Stat. § 909.01.

    15Wis. Stat. § 909.015(9).

    16For purposes of comparison, Prof. Edward Imwinkelried suggests an 11-step foundation: 1) The business uses a computer. 2) The computer is reliable. 3) The business has developed a procedure for inserting data into the computer. 4) The procedure has built-in safeguards to ensure accuracy and identify errors. 5) The business keeps the computer in a good state of repair. 6) The witness had the computer read out certain data. 7) The witness used the proper procedures to obtain the readout. 8) The computer was in working order when the witness obtained the readout. 9) The witness recognizes the exhibit as the readout. 10) The witness explains how he or she recognizes the readout. 11) If the readout contains strange symbols or terms, the witness explains the meaning of the symbols or terms for the trier of fact. Edward J. Imwinkelried, Evidentiary Foundations, § 4.03[2] (6th ed. 2005). Attorney M. Sean Fosmire suggests an updated version of Prof. Imwinkelried's checklist in his article Refining the Standard: Authenticating Computer-Based Evidence, Law Library Exchange Resource Web site, (Nov. 3, 2006).

    17United States v. Tank, 200 F.3d 627, 630 (9th Cir. 2000) (holding there are no set requirements for admission of chat room logs); see also United States v. Scott-Emuakpor, 2000 WL 288443, at *13-*14 (W.D. Mich. 2000).

    18Tank, 200 F.3d at 630 (holding arguments about authenticity of chat room logs went to weight, not admissibility, of chat logs). Cf. State v. Sarinske, 91 Wis. 2d 14, 44, 280 N.W.2d 725 (1979) (holding photographs of footprints admitted although footprints not identified as defendant's); Howland v. State, 51 Wis. 2d 162, 171 (1971) (holding victim's lack of certainty about boots offered into evidence went to weight, not admissibility, of evidence).

    19United States v. Whitaker, 127 F.3d 595, 602 (7th Cir. 1997); United States v. Bonallo, 858 F.2d 1427, 1436 (9th Cir. 1988).

    20People v. Lugashi, 205 Cal. App. 3d 632, 640 (1988) ("[A] person who generally understands the system's operation and possesses sufficient knowledge and skill to properly use the system and explain the resultant data, even if unable to perform every task ... is a `qualified witness'" for purposes of establishing a foundation for the computer evidence.); see also Scott-Emuakpor, 2000 WL 288443 at *12.

News & Pubs Search

Format: MM/DD/YYYY