Search
  • Adam

Documenting IT Reality: Start Here for Digital Discipline


With developments in technology rapidly changing the practice of law, rarely do attorneys find time to come up for air and take a bird’s eye view of Information Technology (“IT”), especially in the heat of litigation. It can be tempting to just give up on seeing the big picture and devoting considered thought to the digital maelstrom, at least until there is a case or a rule that makes it unavoidable and usually too late (doing what is urgent and leaving the important but less urgent for never). But with professional responsibilities at stake and the opportunity of this DRI CLE conference to smell the virtual roses, such matters are ripe for reflection.

A year and a half after the latest amendments to the Federal Rules of Civil Procedure, the law is running pathetically to catch up with technology like an office potato trying to catch a bus. Those who predicted an apocalypse or a utopia are still waiting for affirmation. There is no apparent explosion of litigation concentrated around any of the particular issues of focus for the amendments – proportionality as a primary limitation on the scope of discovery, spoliation sanctions reined in by prerequisites and an end to boilerplate discovery responses. There are cases and there are unresolved questions, but the wheels of justice have not ground to a halt nor are they setting any land speed records.

At the same time, cybersecurity has become a daily fixture in the headlines. Litigation over data breaches is spreading, but not like wildfire. The migration to the Cloud and the ubiquity of Internet-connected devices continues unabated, including among lawyers. Virtualization is the rule, not the exception. We are all living in a virtual reality, whether we know it or not. And tomorrow? Driverless cars, artificial intelligence, cyborgs and drones delivering milk…

Notwithstanding the pace of change, there are safe harbors in this roiling sea for lawyers who want to defend clients from e-discovery broadsides without losing ethical wind in their sails. Getting to these harbors may require effort, but navigation is clear and basically simple: identify and describe the Information Technology environment you face. Lawyers are presumably good at putting things into words and this ability serves them well in the face of technology. Even better – (good) litigators can take the thoughts of all kinds of experts and express them in clear language and compelling format that normal people can understand. Come to think of it, no one is better suited for the work that has to be done.

What am I talking about? Keeping your eye on the ball, so to speak. As technology talk becomes more abstract, imprecise language causes understanding to veer from reality and engender chaos or at least sub-optimal action. Consider the famous mishap in the landmark e-discovery case, Zubulake v. UBS Warburg, where a lawyer misunderstood a client custodian’s reference to email in an “archive” to mean backup tape. This misunderstood source caused the email to go undiscovered. Sanctions ensued.

Simply put, there is one course of action that has been and will continue to be the very foundation of doing anything sensible when it comes to legal compliance and security of systems and data—identifying, understanding and documenting them. Ladies and gentlemen, introducing the venerable “Data Map” (a/k/a “Systems Overview”) and its sibling “Data Classification.”

If we can “reduce” our IT “assets” to words, we can start to build on those words to create the necessary legal framework, which in turn allows us to select the right option when we need to act upon the assets, e.g., preserve, collect, search, etc. By the same token, identifying and understanding these IT assets allows the building of appropriate policies, procedures and controls for purposes of regulatory compliance or cybersecurity. It is possible to reverse the order of operations, but this would be like laying the foundation after erecting the walls and roof—not recommended.

This kind of foundation-laying activity is an ideal opportunity for collaboration between legal/compliance and IT. The first step is gathering existing documentation. If any exists, it is reviewed in preparation for questions seeking missing information, either or both in writing or oral. The documentation is used to identify areas that need clarification, as well as gaps in information and also documentation. Documentation itself is a subject of the exercise as the point is to have quality, useful documentation, so that the fact-finding exploratory mission into the IT world—notwithstanding that it is fun and also iterative--does not have to be repeated at unnecessary additional expense.

The lawyers (presumably) know what facts they need about the IT environment when the environment becomes the focus of preservation and discovery efforts. Similarly, compliance experts know what is important from a regulatory or internal policy perspective. A prominent example for both camps is de facto retention periods.

Certain types of systems are common to almost all enterprises while others may be specialized by industry, product or service, etc. Requests for documentation should cover any and all of these systems, including without limitation: a) communications systems, such as electronic mail and instant messaging, but also telephony and e-mail archiving systems, b) file storage systems, such as network shares and other collaboration systems used to house documents generated by word processing, presentation programs, spreadsheets, etc., c) database systems such as accounting and HR systems, and backup protocols for all of the foregoing. Different functional units may use specialized systems, for example, for software development or securities trading.

Increasingly common is the use of a multitude of “Cloud” or Internet computing services provided by external parties, e.g., Salesforce, Box. Combine this phenomenon with the ubiquity of BYOD and the general trend of rapidly blurring boundaries between business and personal use of IT, and it is no longer possible to acquire a complete picture of enterprise IT from the department dedicated to its maintenance and operation. This is known charitably as “Distributed IT.” Questionnaires distributed over the network to designated employees that collect responses into a database can be extremely useful tools for understanding the Distributed IT world beyond the IT department. Just remember that perfection is the enemy of the good and the information gathering and updating is an ongoing, never ending process.

Another category that should be explored is IT asset management and the assets deployed. How does the enterprise track the computers and other devices or equipment it provides or allows into its network? What is the basic configuration of laptops distributed to the sales force? Are they backed up? Since most investigations and litigation discovery efforts are driven by identifying custodians, these systems are important to finding out where electronic evidence resides and under what conditions. For example, if it is discovered that a departed employee is a key witness and the company redeployed his computer, the lawyers will want to know where it is and whether the process used to re-configure the device for the next user might permit forensic recovery of relevant data lurking in device storage.

With the increased focus on data security, systems that collect data on network and system events have become more popular with lawyers. For example, it can be useful to know who accessed which files and whether they were printed, moved or deleted. Understanding retention periods for many system logs can be critical, as they are often expunged frequently because of the large volumes of data constantly washing over them.

The legal and compliance professionals will assemble all of this information into a narrative, overview document with appendices containing inventories, diagrams or other documents useful for providing more specific information about the systems treated in the overview (for example, applications inventories and network topology maps). With this work product in hand, one can methodically approach development of procedures and controls for the systems and data without, for example, worrying that in the rush to gather documents responsive to a subpoena a trove of ESI from an undocumented system was overlooked.

Understanding systems is critical and necessary, but so is understanding the data created, stored, used and transmitted with all of their hardware and software. For regulatory purposes as well as for security and more general “information governance,” classification of data is necessary. There are an infinite number of ways to classify information, choices among which will depend on a variety of factors such as regulatory requirements, business value, and the practical aspects of implementing the classification scheme. Examples of classification schema include:

  • High, Medium, Low

  • Internal Use Only, Confidential, Public

  • Restricted, Sensitive, Unrestricted

  • Highly Protected, Sensitive, Commercial-in-confidence, Public Domain

  • Extreme, High, Mild, Low

  • Catastrophic, Very High, Noticeable, Minor, None

  • Top Secret, Secret, Confidential

  • Etc., etc., etc.

At the end of the day the scheme is in place for a purpose, for example, identifying information subject to regulatory requirements, data demanding enhanced security measures or determining disaster recovery contingencies. Therefore, it is perfectly acceptable to use different schemes for different purposes. There is no single “correct” scheme but rather many useful ways to classify.

The user and the use should be considered if practicality is important, and it always is in the business context. This means that how data is identified as belonging to one class or another is important. One approach would require users to label data; think of the digital equivalent of using an ink stamp to mark documents “confidential.” There are tools available commercially to facilitate this type of approach, although it is hard to see how it would be practical with a data type such as email. Is it sane to imagine that a user will sort each email by category, even if all that sorting involves is clicking on a blue, red or green button?

Apart from the issue of distraction from business function, many organizations do not accept the idea of leaving compliance to the discretion of individual users where it is possible to automate the task. They may opt instead to simply label “confidential” all data in certain systems, used by certain departments, accessible to certain user accounts or enterprise-wide, or simply apply the protective measure the label is meant to indicate, for example, encrypting all email. This is usually the more prudent and common approach.

Some tools identify data that may be subject to special requirements, using patterns to find, e.g., social security numbers or credit card numbers. These tools are useful to a limited extent, although once the information is identified for selective treatment within other systems or files, the organization needs the tools to apply the right treatment or controls selectively. For example, Data Loss Protection systems can flag emails potentially transmitting credit card information externally for review or blocking.

Once systems are identified and understood and data is sorted and classified, they can be examined in turn to determine appropriate processes for preservation, security controls, retention periods or whatever other legal/compliance treatment is under review. It seems like an obvious necessity, and that is why it may develop into an independent legal requirement for certain businesses. Yet experience suggests that identifying and describing systems and data is an exercise that is not consistently performed in most organization. Lawyers who can help their clients get this done have delivered a major advantage.


0 views