13 May E-discovery nightmare: Does your company know how to respond?
Madison, Wis. – Now that the federal rules of civil procedure have been updated to cover electronic documents, e-discovery is creating nightmares for American businesses.
The headlines seem to come one after another:
• “88,000 patients at risk after computer theft.”
• “6,000 patients have data put online.”
• In Wisconsin, “260,000 Social Security numbers visible on state mailings.”
“You can’t roll out of bed without seeing some of these stories,” said attorney Erik Phelps, a partner in the law firm Michael Best & Friedrich.
Juries are rendering multi-million dollar verdicts, and angry judges that encounter corporate foot-dragging or companies that do not adequately communicate their own data-retention policies are imposing punitive sanctions.
In this environment, the organizational mindset must be that a data breach, followed by an e-discovery request, is not a matter of “if” but “when.” Yet in a 2008 WTN survey, 44 percent of respondents either disagreed or strongly disagreed that their organization is well prepared to handle an e-discovery process as part of litigation. Only 7.8 percent strongly agreed that their company is well prepared.
That probably won’t last, however. Gartner, the Stamford Conn.-based information technology research company, forecasts that spending on electronic discovery software technologies will grow by more than 35 percent annually through 2011. This includes search, content-management, and records-management technology.
Technology aside, the first step in preparing for the inevitable is an incident-response plan. Companies that don’t have an incident-response plan should develop one, Phelps said, because no organization should put itself in a position to learn lessons “on the fly.”
Elements of a plan
During the 2008 Digital Healthcare Conference, Phelps and others said incident response should take into account a number of steps that begin with the restoration of normal business operations and conclude with an examination of whether business processes contributed to a breach.
According to Phelps, the elements of an effective incident-response plan start with an organizational structure that funnels security concerns to a central point of contact. Is there a team, complete with a list of phone numbers, dedicated to handling an incident? Does that team reside in the information technology department or elsewhere? Should there be an incident commander, such a risk manager, in command of the response scenario?
In consultation with legal counsel, organizations should think about the scope of authority granted to the incident-response team: full authority (including investigative authority and the power to shut down any of its own operational systems to protect the business), partial authority, or simple advisory authority.
Many breaches are inside jobs done by wayward employees, but whether the damage is done from within or from the outside, Phelps said employees should be trained to look for anomalous activity. Things that are outside the norm, such as the inability of customers to process payments online, even as the website works well internally (a sign of a phishing scam), should be easily detected by workers.
Such episodes should be investigated until a root cause is found. “I suggest you err on the side of escalating and investigating because you don’t want to be the guy that didn’t,” Phelps said.
Response plans should take into account the possible need to investigate in a forensically sound manner, Phelps indicated. Forensic evidence can be challenged, so it would be wise to develop a relationship with an outside forensic company, one that can offer planning advice, if that capability does not exist in-house.
What about alerting law enforcement? In the event of a credit-card breach, that will happen eventually, but not before the company has a chance to thoroughly investigate. “When you inform law enforcement, you may not have complete control of the situation,” Phelps said. “Ultimately, you will involve law enforcement.”
Phelps also said it’s a good idea to establish relationships ahead of time with law enforcement entities like the FBI’s infrastructure protection partner Infragard and use resources like Carnegie Mellon’s CERT, a clearinghouse for incident response information.
Providing assistance to impacted customers is not only an obligation, it’s one way to preserve the organization’s reputation. After mailing notices with visible Social Security numbers, the Wisconsin Department of Health and Family Services directed the responsible vendor, Electronic Data Systems, to provide free credit monitoring protection for the people affected by the mailings, said Denise Webb, E-health program manager for the department.
“We had an in-depth look in ours and other agencies by Metavante,” she added, referring to a directive from Gov. Jim Doyle. “They looked at everyone’s security and privacy practices, they did and audit, and they came up with recommendations that our department has put in place.”
(DHFS has since ended the practice of using Social Security numbers as personal identifiers, and Doyle has called on other state agencies to follow suit.)
A review of business processes and practices also may be in order because a data breach could be repeated if it’s the result of faulty processes. For example, is the data stored on mobile computing devices encrypted? If so, the damage done by a lost or stolen laptop is reduced to simple theft.
“The issue is putting together processes that prevent it from happening to reduce the risk,” said Dr. Barry Chaiken, founder and chief medical officer of DocsNetwork and chairman of the Digital Healthcare Conference.
Reducing risk is the ultimate goal, Phelps indicated, because no system is foolproof. “You can never make a system fool-proof,” he said, “because fools are so ingenious.”
An emerging issue is the management of the massive amounts of data being produced by healthcare IT. To head off the potential for system failure, CIOs are looking for ways to archive older segments of this data on older and slower storage it technology, but they should approach their solution with e-discovery needs in mind.
When deciding what to archive, Phelps said one question to ask is: “Will we have e-discovery problems?”
Prevention and retention
In healthcare organizations, discovery requests for a growing body of stored and archived electronic data have the potential to create logistical headaches, but that is amplified by failure to adhere to data-retention policies.
Some role-playing by attorneys at the Digital Healthcare Conference demonstrated how organizations get themselves into trouble even when there is no intentional wrongdoing.
Under one hypothetical scenario, an organization with a policy of keeping customer-complaint records for seven years failed to retain some of those documents because they were expensive to transfer when computer systems were replaced – a violation of the document-retention policy.
In another case, documents were destroyed as part of a regularly scheduled deletion, but well after a lawsuit was filed and a litigation hold was in place. Organizations may need to hold documents at the point where they believe they might be sued, not on the date a lawsuit is filed, because at this point they should be engaged in a fact-intensive analysis, Phelps said.
Even if the documents were not intentionally destroyed to conceal evidence in a legal case, a judge may instruct the jury to proceed as if they had under what is called an “adverse inference instruction.”
“If you game the process and anger the judge, credibility issues will be looked at differently,” said attorney John Scheller of Michael Best & Friedrich. “The baseline is adhering to a document-retention policy.”
• CIO Leadership: Mercy’s Fred Terry fights digital data explosion
• Mark Foley: Data privacy fix broader than Social Security numbers
• Mark Foley: Expert testimony may be needed for e-discovery keyword searches
• E-discovery case law trends beginning to emerge
• John Flanagan: Document retention policy can get your arms around e-discovery