The chief reason you need a data breach response plan is that the likelihood of a breach of personally identifiable information (PII) affecting your organization is probably already high — and getting higher every day.

Depending on what data is accessed, and how the perpetrators use it, there could be huge repercussions to your organization’s reputation and market value, as well as damage to relationships with customers, employees, vendors, financial partners and others. Even more troubling is that some of the impact may not be felt for months, or even years.

The most effective type of data breach response plan is two-pronged: your response following a breach, and more importantly, what you do before a breach ever occurs.

What to do when hackers have struck

The part of the plan that may come to mind first involves what happens immediately after the breach is detected.

One critical step in your response is to determine exactly what the intruder did while inside your firewall and which records they breached. You need to get in a room with your IT staff and technologists to identify the specific applications or systems through which the hacker breached to identify the specific components of the underlying data asset(s) at risk (i.e., the database, repository, cluster, collection, etc.).

This meeting should include application developers, data management and administrative staff, and solution architects. It is also important to include the data stewards who support any business data element that was exposed, in order to give them a jump start on revising data quality monitoring rules and data access policies. It’s important to start this step early, as these activities often require significant time. The goal in the first 5-10 days following the breach is to develop an action and remediation strategy to stop the bleeding and prevent additional hacks.

A second step is to coordinate the non-technical efforts of your communication/PR, finance, and legal teams. If you’re in a heavily regulated industry, such as financial services, pharmaceuticals or healthcare, this team could also include your compliance area. In general, you’ll need to develop messages to each type of stakeholder explaining what happened, what you’ve done to address the problem, and what resources you may be able to provide to minimize the impact. If your legal and/or financial teams haven’t done so already, it may be wise to allocate funds to a reserve account to cover future litigation and PR costs, in case a significant breach occurs.

What you should do now

As important as it is to have a plan for how to react after the breach, the more important part of your plan concerns what you do before the breach even takes place. This is where you have a far greater ability to limit the damage.

One of the underlying insights that makes your data breach response plan achievable is to recognize that not all data represents the same level of potential danger to your organization if it is stolen and released. For most organizations, the most potentially explosive data by far is the “Holy Grail” for a hacker: data elements that enable them to expose, extort or leverage another individual. These highly sensitive data elements can range depending on the industry, but in general a key category of data elements is that of PII.

Many organizations only focus on managing individual data elements within their PII assets. However, it is actually the combination of data elements that creates the most risk in breaches. For instance, if a birthdate alone were exposed, not much would happen as a result. If birthdate, email address, birthplace and age were also exposed, this could provide a fairly robust set of materials for hacking into other accounts (i.e., bank, credit card, personal email, etc.). In this example, it would be critical to capture and manage the relationships of potentially risky data element combinations. If you are only capturing “information security classifications” for each individual data element, you are leaving dangerous gaps in your organization’s armor.

The key is to remember that you may have customers’ or clients’ SSNs spread through your information systems. Many of these locations are easy to find and lock down — fields in customer databases labeled “Social Security Number,” for example. But other instances may not be so accurately or intuitively labeled, and thus might not readily come to mind.

This is why it’s so important, while you have the luxury of time, to conduct a methodical data inventory and gather relevant metadata to understand exactly where your most sensitive data resides, who accesses it and how they use it. This gives you the ability to focus your encryption, masking, obfuscation and other preventive efforts — and also lets you know exactly which databases and systems you need to lock down as soon as you know you’ve been hacked. Again, if you are leveraging a robust metadata management capability AND you are working to identify risky data element combinations, it will enable the organization to establish monitoring rules that look for data utilization patterns that feature combinations of risky elements.

By creating a data breach response plan based on a clear understanding of where your sensitive data exists — all of it, not just the data in the obvious locations — you can move far more quickly in the event of a breach to lock down databases and repositories, and hopefully beat the hackers to it.

An even more advanced level of preparation is to set up a system to detect suspicious use of sensitive data in real time, and immediately close down whatever repositories are at risk. This requires substantially more work — but it’s certainly doable. Although every organization should be making investments to prevent intrusion, if you have not established what data should be protected in the event of a breach, you are essentially putting all of your eggs in one basket — leaving your data security and breach strategy undiversified.

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers.