Data breach? Here's what to do, when and how

The key is to prepare ahead of time with a contingency plan that details roles, actions and timelines

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?

Well, you might want to obey the 33 or so state laws that govern when and how you should notify the people named in those exposed files, gently breaking it to them that because of you, they're now naked to identity theft. The laws are hardly copies of each other, but the standard bearer is California SB 1386. The California Office of Privacy Protection has 30 pages of recommendations on how to comply with it.

If you're with a financial institution, specific federal laws apply, and the Federal Trade Commission has its own list of recommendations, including a model notification letter.

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 Protegrity Corp., a data security management firm in Stamford, Conn. Taylor, who writes data breach contingency plans, suggested that the committee include representatives from the organization's business units, plus the corporate attorney, 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 Inc.:

  • 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 LLC, a research firm in Elk Rapids, Mich., 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 LLP, a law and technology services firm in Dallas.

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 underreact 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 harbor."

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% will be privacy-centric enough to change their behavior, 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 center 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% of the people who receive notification will call and ask questions, but the number can rise to 50% in cases where employee data is breached.

If offered free credit monitoring services, about 30% 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% 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% in the overlap population. Then about 2,000 people who were involved in those two breaches were involved in a third breach, and rate of churn among those 2,000 was nearly 100%."

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 center.

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 favorite place to live is in denial, accepting the risk and not talking about it."

Lamont Wood is a freelance writer in San Antonio.

Copyright © 2007 IDG Communications, Inc.

It’s time to break the ChatGPT habit
Shop Tech Products at Amazon