Seven Things Every Litigator Should Must Know About Metadata

By Christian E. Dodd on behalf of the Electronic Discovery and Digital Evidence Committee, Business Law Section of the Florida Bar

To abide by their ethical duties, litigators must, not should, but must understand certain aspects of metadata. On what basis do I make this statement, you might ask? My response is that the American Bar Association and no less than 20 states have said as much.

In 2012, the ABA amended Comment 8 to Model Rule 1.1, concerning competence, to provide that maintenance of the requisite knowledge and skill requires lawyers to “keep abreast of changes in the law and its practice, including the benefits and risks associated with relevant technology”.[1] No less than 20 states have followed suit by adopting a duty of technology competence in some form.[2] And metadata frequently is a by-product that results from the use of technology. For example, a litigator who uses a software application like MS Word to create a document—a pleading or motion, a letter to opposing counsel, etc.—creates metadata. Also, as discussed herein, metadata produced or obtained in discovery might make or break a case. Consequently, to maintain his or her duty of competence, every litigator must have an understanding of metadata.

Here are seven things that every litigator should must know about metadata.

1. What metadata is.

Metadata is information generated by a computer operating system or other software program that is associated with a particular electronic file. Simply put, metadata is data (or information) stored in electronic form about other data (or information) stored in electronic form.

Generally, there are two main types of metadata: system metadata and application metadata.[3] System metadata (also referred to as directory level metadata) is data about an electronic file supplied by the computer’s operating system (e.g., Microsoft Windows). To see an example of system metadata, open a Microsoft Word file and select the File tab, then select “Info” and then from the “Properties” drop down menu, select “Advanced Properties”. Examples of system metadata include the “Created”, “Modified” and “Accessed” dates that appear on the “General” tab. These timestamps are derived from the clock settings of the operating system.

Application metadata (also referred to as file-level metadata) is information about a specific electronic file that is created by the application itself. Using the same Microsoft Word file in the prior example, follow the same sequence of steps above. Examples of application metadata include the author name and comments on the “Summary” tab and the various document statistics (pages, paragraphs, lines, etc.) on the “Statistics” tab. Different applications create different types of application metadata. Thus, the application metadata created by Microsoft Word is not the same as the application metadata created by Microsoft Outlook.

2. Where metadata is stored.

Metadata is often stored internally (i.e., embedded) in the electronic file itself. When stored internally, the metadata travels with the data to which it relates. Thus, when a copy of an electronic file is made (such as when a copy of a file is attached to an email), the internal metadata associated with the original file is included with the copy.

In some instances, metadata is detached from the main data and stored in a repository, such as a database. One common example of this occurs in litigation when the metadata associated with an electronic file is stored in fields in a database and an image of the electronic file is associated with these fields. For example, an email message may be converted from its original message format (such as .msg) to a Tagged Image File Format or “TIFF” file. Metadata from the electronic email file—such as the email address for the sender of the email and all recipients (including cc’s and bcc’s)—is stored in an e-discovery database. If the email is responsive to a document request, the TIFF file is produced along with a database file (called a load file) that contains some or all of the metadata associated with the original email message.

3. How to avoid disclosing confidential or privileged metadata.

Because internally stored metadata travels with the electronic file to which it relates, it is possible to unintentionally disclose information that is confidential or protected from disclosure by the attorney-client privilege or attorney work product protection. This can occur when an electronic file for a pleading or motion is uploaded to a court’s electronic filing portal. Lest there be any doubt, it is the lawyer—and not the court clerk—who is responsible for stripping the metadata from the electronically filed document.[4]Confidential or privileged information contained in metadata might also be disclosed when an electronic file is attached to an email sent to counsel for an opposing party or a third-party. In either instance, if metadata is not scrubbed—i.e., removed from the electronic file—before transmission, it may fall into the hands of an unintended recipient.

There are numerous metadata scrubbing software applications, many of which integrate with email and other software programs. Before transmitting any electronic files to any other party, person or entity, litigators must consider whether the file contains metadata that should be scrubbed. In some instances, counsel might even scrub embedded metadata from an electronic file before forwarding it to the client. There are numerous ways in which a properly utilized metadata scrubbing application might save counsel from an embarrassing situation, a breach of the duty of confidentiality, or worse.

4. How metadata might be relevant to a case.

By becoming aware of the various forms of metadata that may exist, a litigator has a greater understanding of evidence that may be available to support or refute the claims and defenses in a case. Consider the following example: Plaintiff sues Defendant alleging breach of a contract that was entered into by the parties nearly five years ago. The dispute centers on the proper interpretation of a key contract term. The meaning of this term was discussed and mutually agreed upon at a meeting of Plaintiff’s Operations Manager and Defendant’s Vice-President of Sales, which took place shortly before the contract was executed. During this meeting, Defendant’s VP of Sales took handwritten notes. Two days later, Defendant’s VP of Sales had her handwritten notes transcribed to a MS Word file after which the handwritten notes were misplaced (or destroyed). Plaintiff’s Operations Manager did not take any notes at the meeting.

It does not take much imagination to realize the potential importance of the electronic file consisting of the transcribed notes to the outcome of the litigation. But consider also the potential importance of the metadata. What if the metadata indicates that the MS Word file was created two years, and not two days, after the meeting discussed above? What event triggered the transcription of the notes—and destruction of the original handwritten notes—at this late date? Or what if the metadata indicates that the MS Word file was modified shortly before, or shortly after, the dispute arose? Or, perhaps the metadata indicates that after the MS Word file was created, it was viewed and edited by Defendant’s CEO, who was not present at the meeting to which the notes pertain. If any of these things occurred, Defendant has some explaining to do regarding the accuracy and reliability of the MS Word file. In other words, there may be critical issues concerning the foundation and admissibility of the handwritten notes. Alternatively, if the metadata reflects that the notes were transcribed two days after the meeting, immediately reviewed by the VP of Sale, and never modified thereafter, Defendant might use this information to bolster its arguments that the MS Word file should be found admissible and that it accurately reflects the substance of the conversation at the meeting. But if the lawyers representing the parties are not aware of or considering the potential relevance of metadata, this critical evidence may never come into play.

5. Parties to litigation have a duty to preserve relevant metadata.

Simply put, if a party to an existing or impending lawsuit has possession, custody or control over metadata that is relevant to the dispute, the party has a duty to preserve it. Like all other relevant electronically stored information, metadata must be preserved once the duty to preserve has been triggered. Importantly, however, metadata can be inadvertently modified even when the content of the main document is left untouched. For example, simply opening an electronic file to review its contents can have the effect of altering certain metadata. Consequently, it is important to be vigilant about preserving metadata as soon as the duty to preserve is triggered.

Clients should be explicitly advised of their duty to preserve relevant metadata. Litigators should not assume that their clients understand metadata, appreciate its potential importance to a lawsuit, or are aware of the duty to preserve metadata. Litigators should explicitly advise their clients in writing about these issues. The following is a sample paragraph that can be included in a broader litigation hold letter to a client:

“The evidence that must be preserved includes relevant metadata. Metadata is information generated by a computer operating system or other software program that is associated with a particular electronic file. In other words, metadata is information stored in electronic form that concerns other information stored in electronic form. As an example, the substantive content of a MS Word file (e.g., the words on the page if the file is printed) is data. if relevant, this data must be preserved. Information about when the MS Word file was created or last modified is metadata. If relevant, this metadata also must be preserved. To err on the safe side, all metadata that is associated with relevant data should be preserved. If you (or your IT personnel) are unsure how to ensure that relevant metadata is preserved, please let me know.”

The final sentence in this paragraph may give you pause, as you may be thinking “I don’t have the technical expertise to advise clients how best to preserve metadata.” The good news is that you don’t have to in order to assist your clients. You can engage or associate with other professionals—lawyers, e-discovery vendors, IT professionals, etc.—who can assist your clients with these types of technical issues. Ask yourself this question: Do you better serve your client by providing advice about the existence of a duty but are unable to lend any advice about how your client can go about fulfilling the duty, or by pointing out the duty and providing a resource who can assist your client with the technical aspects of fulfilling the duty? (One alternative, of course, is to simply not advise the client of the duty in the first instance and hope that metadata never becomes an issue in the litigation. The potential pitfalls of proceeding in this manner should be evident.)

6. How to ask for and obtain metadata from other parties.

Rule 1.350 of the Florida Rules of Civil Procedure provides that a request for electronically stored information may specify the form or forms in which the ESI is to be produced. Consequently, a requesting party can specify that ESI is to be produced in native file format with all metadata intact. Alternatively, a requesting party can specify that ESI be produced in a non-native format (e.g., TIFF images) with metadata included in an accompanying file (e.g., a database load file). Further, a requesting party can craft a definition of “Document” that includes all associated metadata.

Rule 1.350 further provides that if the responding party objects to the requested form, the responding party must state the form or forms it intends to use. In the event the requesting party is not satisfied with the basis for the objection and form(s) in which the responding party intends to produce ESI, the requesting party can move to compel production in the requested form. If it becomes necessary to make such a motion, the requesting party should be prepared to argue why the metadata is relevant and sought, as well as why the form proposed by the responding party is insufficient. For a good discussion of these issues, see Independent Marketing Group, Inc. v. Keen, No. 3:11-cv-447-J-25MCR, 2012 U.S. Dist. LEXIS 7702, 2012 WL 207032 (M.D. Florida Jan. 24, 2012).

7. When and how to negotiate issues concerning the preservation and production of metadata.

At the outset of a case, counsel should contemplate the categories of substantive documents and ESI that may be relevant to a dispute. Likewise, counsel should consider whether the metadata associated with these categories of ESI are relevant. Rather than allowing metadata to be a trap for the unwary or a costly sideshow to more substantive document discovery, counsel should proactively discuss and attempt to agree upon which types of metadata might be meaningful in a particular dispute. If agreement is reached to produce electronic files in their native file format, this generally becomes a non-issue because the metadata is included with the produced native file. However, if electronic files will be produced in some other format (such as TIFF or .pdf files), then counsel should consider and discuss whether some or all of the associated metadata also should be produced.

To facilitate this discussion, counsel should first identify the types of electronic files likely to be relevant and produced in discovery and then familiarize themselves with the metadata associated with these files. If the metadata is required to establish foundation or admissibility, or likely to bear on the substantive issues or lead to the discovery of other admissible evidence, then the requesting party will likely want the metadata to be included in the producing party’s production. But if the metadata is unlikely to be meaningful, the requesting party might agree to forego it. By communicating and reaching agreement on these issues at the outset of litigation, parties might avoid the unnecessary effort and expense associated with preserving and producing irrelevant metadata.

Christian Dodd is a partner with Hickey Smith LLP. His practice is focused on complex business litigation, intellectual property matters, government investigations and electronic discovery and information governance issues. Christian has extensive experience managing the discovery lifecycle in the context of both small- and large-scale litigation and government investigations. He draws on this experience to devise strategies, including legal process workflows and automated document assembly templates, to improve efficiencies and reduce the costs of litigation.

[1] Model Rules of Prof’s Conduct R. 1.1 cmt. 8 (2012) (emphasis added), available at http://www.americanbar.org/groups/professional_responsibility/publications/model_rules_of_professional_conduct/rule_1_1_competence/comment_on_rule_1_1.html.

[2] Robert Ambrogi, 13 15 17 18 20 States Have Adopted Ethical Duty of Technology Competence, Law Sites, March 16, 2015, http://www.lawsitesblog.com/2015/03/11-states-have-adopted-ethical-duty-of-technology-competence.html.

[3] At times, information known as embedded data is also referred to as metadata. Embedded data consists of information that is input into a file by the user which typically is not directly visible in the output file. For example, the formula in a particular cell of a MS Excel file may not be visible, but the resulting value calculated by the formula would be visible in a printout of the spreadsheet. Whether or not referred to as metadata, embedded data can be a critical part of an electronic file.

[4] Gary Blankenship, Lawyers are responsible for stripping metadata from all e-filed documents, The Florida Bar News, June 15, 2015, available at https://www.floridabar.org/the-florida-bar-news/lawyers-are-responsible-for-stripping-metadata-from-all-e-filed-documents/.

VIEWS AND CONCLUSIONS EXPRESSED IN ARTICLES HEREIN ARE THOSE OF THE AUTHORS AND NOT NECESSARILY THOSE OF FLORIDA BAR STAFF, OFFICIALS, OR BOARD OF GOVERNORS OF THE FLORIDA BAR.