A Bit About Data Mapping

http://ow.ly/6F13b

An article by Craig Ball, Esq. appearing on his blog Ball in Your Court.

This detailed article discusses a webcast that Craig Ball, Esq. recently conducted regarding data mapping.  The author provides some significant information regarding the process of data mapping, including defining what it is, and offering insight into how to properly perform the function.

Mr. Ball points out, "I use “data mapping” to describe methods used to memorialize the identification of ESI–an essential prerequisite to everything in the EDRM east of Information Management. Of course, like Nessie and Bigfoot, Information Management is something many believe exists but no one has ever actually seen. Consequently, identification of ESI, viz. data mapping, is the de facto entry point for all things e-discovery."

The author further states, "Unless created expressly for e-discovery, few companies have any diagram approaching what’s required to serve as an EDD data map. Neither network diagrams from IT nor retention schedules from Records and Information Management are alone sufficient to serve as an EDD data map, but they contribute valuable information; clues, if you will, to where the ESI resides."

There are some logical points of concern pointed out by the author, such as "The duty to identify ESI is the most encompassing obligation in e-discovery. Think about it: You can’t act to preserve sources you haven’t found."

Some additional tips provided by the author are as follows:

"Creating a competent data map is also akin to compiling a history of:

• Human resources and careers (after all, cases are still mostly about people);
• Information systems and their evolution; and
• Projects, facilities and tools.

A data map spans both logical and physical sources of information. Bob’s e-mail is a logical collection that may span multiple physical media. Bob’s hard drive is a physical collection that may hold multiple logical sources. Logical and physical sources may overlap, but they are rarely exactly the same thing.

1. As needed, a data map might encompass:
2. Custodian and/or source of information;
3. Location;
4. Physical device or medium;
5. Currency of contents;
6. Volume (e.g., in bytes);
7. Numerosity (e.g., how many messages and attachments?)
8. Time span (including intervals and significant gaps)
9. Purpose (How is the ESI resource tasked?);
10. Usage (Who uses the resource and when?);
11. Form; and
12. Fragility (What are the risks it may go away?).

This isn’t an exhaustive list because the information implicated changes with the nature of the sources being inventoried. That is, you map different data for e-mail than for databases."

The article provides some additional tips and suggestions.  In addition the author provides 3 key points to address:

• Accountability is key every step of the way
• Where you start matters less than when and with whom
• Just because your data map can’t be perfect doesn’t mean it can’t be great.

If you are interested in this topic, this article is certainly worth reading, as Mr. Ball's articles generally are.