Public Data Breach Disclosure: The Five Keys to Making the Best Out of a Bad Situation

George V. Hulme

February 05, 2016

Public Data Breach Disclosure: The Five Keys to Making the Best Out of a Bad Situation

Enduring a major data breach is certainly bad, but it can be made worse by botching the public disclosure of that breach. A lot worse.

It goes a long way to further crumbling trust and public goodwill that is already shaken by the breach. 

All of this costs the organization dearly in brand and the trust of customers, partners, suppliers, employees, and regulators. Not good. Over the years, we’ve all witnessed enterprise breach disclosures that were handled badly.

Sometimes, the disclosure is botched because it comes way too long after the incident and the facts are known; other times, the company doesn’t seem to grasp the magnitude of the breach. And then a breach that wasn’t important suddenly escalates to a major incident, or one that involved only a few thousand records is suddenly hundreds of millions. Or an incident once attributed to China is now known to be the work of a disgruntled insider. One can’t blame the public and those directly affected for losing confidence in the organization.

None of that is the outcome anyone wants. Customers don’t want it, shareholders don’t want it, and certainly the business doesn’t want it. The best way to avoid the fully avoidable backlash of a bungled breach response is to have a plan and be able to execute against that plan.

Here are five important things any organization should do long before it is breached and find that they have to publicly disclose a data breach:

Key Number 1: Build an effective incident response team

This should go without saying, but today too many organizations still don’t have the capability to technically detect and respond to a data breach. How do I know that most organizations don’t have the ability to spot and respond to data breaches? According to a survey of detected breaches, most of those who are successfully attacked don’t learn from their internal systems; rather, they are informed by third parties such as partners, customers, or law enforcement.

Key Number 2: Know whom to contact

In the confusion during the heat of the incident, some information is bound to be foggy, and tough decisions are going to have to be made. It’s important that the involved groups attain familiarity with the others and know what is expected of each individual or team. Who will be in charge of what aspects of the breach investigation, decision making, and outreach to law enforcement, HR and legal decisions, regulators, and so on? It is essential that these be planned out ahead of time.

However, once it’s determined that an incident is serious enough to notify business leadership, the people and the protocol for this need to already be in place. That includes informing members of the legal and compliance teams, the CIO’s office, corporate communications, and others. Once the legal, business, and regulatory implications of the breach are understood, it’s time to take the incident to executive management and eventually notify the affected stakeholders.

This is one of the major reasons why organizations tend to fail at response. In a large way, they don’t know who is supposed to do what, then communications and processes break down, and the entire situation goes sideways.

Which brings up the next key.

Key Number 3: Craft a plan

Assuming that the breach is significant, and the breach requires you to publicly disclose, you are going to need a plan. The people and departments in Key Number 2 will need to know how to interact with each other and what everyone’s responsibilities are. After you craft a plan, you need to practice that plan. This way, when something happens, the organization knows what to do.

Unfortunately, this is where many organizations fall short. When they approach their customers or announce a breach, they don’t do so as well as they should, which can cause loss of trust, loss of customers, and even increased regulatory scrutiny.

How does an organization brace for the potential blowback from a breach? Build a plan that enables the organization to know what is happening, what data were gathered, why, and everything else that can be understood about the scope of the breach. Connect the dots so that press and customer questions can be answered, and that regulators can (hopefully) be shown that reasonable due care had been taken to avoid the breach. The idea isn’t to hide anything here, but to be prepared to deal proactively with any potential fallout that is bound to happen and provide the community and customers the answers they deserve to hear.

Having the communications and action plan in place is crucial. What will be remembered isn’t necessarily the breach but how badly mistakes were made in the aftermath.

How do you practice the plan? Most CIOs and CISOs I’ve spoken with say they conduct tabletop exercises. Gather the team leaders, develop a few breach scenarios, and drill the team on how to interact and the decisions to be made in each scenario.

Key Number 4: Only go public when confident breach is understood

Don’t respond until the facts are known unless a law or regulation dictates otherwise. In some jurisdictions, in my opinion, they do dictate too swift a response or a response in a specified period of time regardless of completed analysis. Too many breach disclosures today are announced initially with a relatively low number of data breaches; then that number slowly escalates over time as more about the nature of the breach is understood. This is a death by 1000 cuts; it is damaging to the business and erodes trust among investors, partners, regulators, and customers.

Key 5: Bring to resolution

Take care of those affected in the best way the organization can: apologize and make it clear that the enterprise understands what went wrong and that the condition that made the breach possible was resolved and mitigated. Move the focus to resolution and make sure to actually mitigate whatever went wrong.

Dealing with a data breach that requires public disclosure is never easy, but it’s likely to be a lot easier and go more smoothly with the right plan in place. 

Contact an expert

 

tags


Author


George V. Hulme

George V. Hulme is an internationally recognized information security and business technology writer. For more than 20 years Hulme has written about business, technology, and IT security topics. From March 2000 through March 2005, as senior editor at InformationWeek magazine, he covered the IT security and homeland security beats. His work has appeared in CSOOnline, ComputerWorld, Network Computing, Government Computer News, Network World, San Francisco Examiner, TechWeb, VARBusiness, and dozens of other technology publications.

View all posts

You might also like

Bookmarks


loader