CIO

Data Breach? Here's What to Do, When and How

If the decision is made to notify, the worst practice is to take the cheap route and communicate by e-mail.
  • Lamont Wood (Computerworld (US))
  • 23 April, 2007 14:07

There's been a data breach. It happened 268 times during 2006 (according to the Privacy Rights Clearinghouse). Now, it's happened to your organization. What do you do? Obviously, the situation is complex and fraught with legal hazards - and the experts agree that your only hope of navigating them successfully is to have a contingency plan written in advance.

"You need practical things like a plan and committee, and a decision about who is going to be on that committee," says David Taylor, vice president at US-based data security management firm Protegrity, who writes data breach contingency plans, suggested that the committee include representatives from the organization's business units, plus the corporate lawyer, the corporate compliance officer or equivalent, someone (such as a public relations officer) who can address the issue of reputation damage and someone who reports to the chief financial officer.

Having convened, there are four things the committee must do, says John Pescatore, an analyst at Gartner:

  • Begin the customer notification process
  • Start the breach containment process
  • Decide whether to involve law enforcement
  • Perform a post mortem

When it comes to notification, the committee should act quickly. "Time is of the essence," notes Larry Ponemon, head of the Ponemon Institute, a US research firm covering privacy, data protection and information security policies. "You want to make sure that you get your message out hours and hopefully days before it appears in the media."

"One of the primary causes of legal action is the accusation that you knew sooner than you told," adds Rob Scott, managing partner at Scott & Scott, a US law and technology services firm.

But while moving fast, "be surgical when identifying who is at risk - a big mistake we see many times is that they think that by casting a wide net they will be seen as a more responsible organization," Ponemon cautions. "Don't send a notification letter to people who don't need it. Those who get the letter will either under-react and do nothing, or overreact and do things that are not required, like throwing away their credit cards or constantly calling credit bureaus. The letter is always seen as a negative issue."

Scott suggests taking a deep breath. "Not every incident requires reporting," he notes. "Does the information meet the express definition of a particular state law? Does it constitute personal information under state law? Does it constitute nonpublic information under federal law? What you have may not be a notice-triggering incident. If the breach is contained and there are no victims, there is no need to report it under many statutes. Also, encryption is almost always a safe harbour."

If the decision is made to notify, "The worst practice is to take the cheap route and communicate by e-mail," Ponemon adds. "People will assume that you wanted the recipient to think it was spam and not open it. Actually, you want to make sure they read it, and use both a letter and a phone call to reach those who are at risk."

Pescatore notes that the recipients may not believe e-mail notification anyway, on the assumption that it's a phishing attempt. On the other hand, he says that the customers should be warned that they are likely to receive phishing e-mails pretending to be from the breached organization, offering to help them - but needing personal information to do so.

"Among those who get the letter about 8 percent will be privacy-centric enough to change their behaviour, and they can cause you a lot of grief by telling their friends and family, contacting their state attorney general and hiring a lawyer to sue you," Ponemon warns. "You can mitigate them by setting up a call centre that offers answers that are factual and succinct. Don't just give a script to the call agents - give out a toll-free number where people can reach someone with enough internal knowledge to get them to the right person."

Ponemon says that in cases where consumer data was breached, about 10 percent of the people who receive notification will call and ask questions, but the number can rise to 50 percent in cases where employee data is breached.

If offered free credit monitoring services, about 30 percent will accept, he says, while many of those who decline apparently assume there is some catch to the free offer. Handing out coupons for goods and services will get a better response from them, Ponemon says, while the best practice is to give the recipients a choice, such as between monitoring, coupons or a credit on their bill.

"But the company needs to decide early on how much support it is going to give, because the worse thing to do is to over-promise," Ponemon says. "If you fail to live up to your commitments, you can really hurt your reputation, and incite anger and lawsuits."

The breach containment process must also begin immediately. "Make sure the breach is not still open," Pescatore urges. "But you must also decide if you are going to try to preserve the evidence. Often, to contain a problem you have to overwrite logs and audit trails that might help you find how the breach happened."

As for contacting law enforcement, "the decision is typically made by the organization's legal counsel early in the process," Pescatore notes. "But there is little to be gained by getting involved in prosecution, since it does not put data back into the database, does not save money and does not help the customers."

In a worst-case scenario involving law enforcement, staff members will find themselves being questioned in separate rooms, often repeatedly. "Everyone starts dummying up," Taylor says. "Everyone starts covering their asses. Everyone is suspicious of everyone else. Nothing gets done beyond crisis management."

The answer, he says, is to rehearse the data breach response plan just like the organization rehearses its disaster recovery plan. And while rehearsing, it might be wise to coach the technology staff on how to answer lawyers' questions, Taylor says. "The first line is to always tell the truth," he says. "The second is not to speculate or go beyond what you know, but to stick to the facts. Answer specific questions and don't volunteer anything. You may not be under oath, but what you say will be written down and then double checked with someone else." Finally, there needs to be a post mortem analysis, to ensure that the original problem won't recur.

"The worst thing is to have additional breaches, or to assume that additional ones will have the same impact as the first," Ponemon warns. "One bank that we studied had a 2 percent customer churn [loss] rate in the first six months after a breach. Then there was a second breach, with some overlap with the victims of the first breach. The churn was 30 percent in the overlap population. Then about 2000 people who were involved in those two breaches were involved in a third breach, and rate of churn among those 2000 was nearly 100 percent."

But unless a plan has been written in advance, a fast, coherent response is unlikely. Taylor says that a data breach response plan should not be more than two pages long. It should be written in an all-day meeting, where the participants decide exactly who is going to be responsible for what activity, such as victim notification, IT forensics, public relations and the call centre.

They need to decide who is going to take over if a responsible party is on vacation, or if the backup person is on vacation. They need to decide how data breaches will be handled on a weekend, or a holiday, Taylor adds.

Additionally, the data breach plan should synch with the disaster recovery plan, and both should be rehearsed, Taylor says.

"Do not just put the plan on the shelf," he says. "The favourite place to live is in denial, accepting the risk and not talking about it."

Lamont Wood is a freelance writer in San Antonio.