Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk

2/21/2007
11:15 AM
50%
50%

When to Disclose a Data Breach

You've discovered a possible security leak. How quickly should you inform customers and employees?

When should your company tell its customers or employees about a suspected data breach? Does it matter?

The simple answer is yes, it does matter. But there is no "one size fits all" rule for every corporation or every situation. The key is to provide timely, accurate, and truthful information to those affected — without sweeping the breach under the rug or waiting too long. Trust me — breaches do not get better with time.

Let’s take a look at the legal, business, technical, and other risk factors weighing on the disclosure decision and discuss the timeline for handling a breach when it occurs at your company.

First, you may have legal requirements for disclosing a suspected breach, depending on the state of residence of those affected. Currently, there are 34 states with different data breach laws in place. That’s right — we do not have a federal law that governs data breaches.

Some of these states have specific guidelines regarding notification. For example, Florida and Ohio require affected persons be notified within 45 days of the breach. New York’s data breach law has a 120-day timeline. So if those affected by your breach reside in one of these states — or another state with hard-coded deadlines — then you have a legally imposed deadline.

Other states do not have specific deadlines. These states use generally use the language of California’s SB 1386 — the first data breach law to be passed in the U.S. — which requires notification within “the most expedient time possible and without unreasonable delay.” What is an unreasonable delay? What is reasonable? In every case, the "reasonableness" of notification depends upon the specific facts of that situation.

If the affected person does not reside in a state with a data breach law, the company must make a business decision — as opposed to a legal determination — as to whether or not to tell that person.

The second factor in the disclosure decision is business reputation. What do your employers and customers expect? The goodwill generated by a name or brand or logo is immeasurable in terms of dollars and cents. Allowing that goodwill to be tarnished by failing to report a breach — or by reporting it late — can cause irreparable harm to a company and its image.

Customers are not afraid to take their business elsewhere if they believe a company is being less than truthful with them. So, from a business reputation viewpoint, it is important to provide timely, accurate, and definitive information regarding a breach.

The third factor has to do with the technical issues associated with the breach. A company needs time to analyze the scope of the breach, lock down the data, analyze/remediate the damage, return the business to full operation, consult with business partners, speak to legal experts — and, in some instances, work with law enforcement. These activities require a great deal of coordination, planning, information gathering, and legal action.

In some cases, there may be other risk factors besides these three. For example, telling others of a breach can lead to FTC action, civil lawsuits, and class action lawsuits. A breach may affect your stock or current business dealings with others. These are important considerations that must involve senior management.

In my practice, I’ve seen all types and sizes of data breaches, ranging from lost/stolen laptops, organized criminal data extortion schemes, insider threats, hacked IT systems, and even software malfunctions. From these experiences, I can tell you that there is no one rule that can be applied to every company or every situation within a specific company.

Sometimes, the scope of a breach requires a great deal of investigation and coordination that cannot occur within a short time period. This is especially true when breaches involve different law enforcement agencies in multiple countries.

What can you do today to prepare for a breach response? Take five different scenarios — you can use the examples I provided above — and prepare a tabletop exercise to work through each situation. Make sure you have the right types of people and expertise to respond to each scenario, and involve senior management in your planning.

Based on population and identity theft statistics, we can say that it’s very likely that your breach will involve a person residing in Florida — a state with a 45-day timeline. That means you’ll have just 45 days to make your disclosure. Work through your breach scenarios several times to improve the coordination and reporting timeline of a breach. Involve outside experts in these tabletop exercises.

Every breach is different. There is no magic reporting timeline that fits every situation, every company, or every business culture. Start planning by engaging in a dialogue with management, running exercises, and analyzing after-action reports.

Once you are satisfied your company has an adequate response plan in place, turn your attention to prevention.

Dr. Chris Pierson is an attorney with the law firm of Lewis and Roca LLP. Special to Dark Reading

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
News
Inside the Ransomware Campaigns Targeting Exchange Servers
Kelly Sheridan, Staff Editor, Dark Reading,  4/2/2021
Commentary
Beyond MITRE ATT&CK: The Case for a New Cyber Kill Chain
Rik Turner, Principal Analyst, Infrastructure Solutions, Omdia,  3/30/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2015-20001
PUBLISHED: 2021-04-11
In the standard library in Rust before 1.2.0, BinaryHeap is not panic-safe. The binary heap is left in an inconsistent state when the comparison of generic elements inside sift_up or sift_down_range panics. This bug leads to a drop of zeroed memory as an arbitrary type, which can result in a memory ...
CVE-2020-36317
PUBLISHED: 2021-04-11
In the standard library in Rust before 1.49.0, String::retain() function has a panic safety problem. It allows creation of a non-UTF-8 Rust string when the provided closure panics. This bug could result in a memory safety violation when other string APIs assume that UTF-8 encoding is used on the sam...
CVE-2020-36318
PUBLISHED: 2021-04-11
In the standard library in Rust before 1.49.0, VecDeque::make_contiguous has a bug that pops the same element more than once under certain condition. This bug could result in a use-after-free or double free.
CVE-2021-28875
PUBLISHED: 2021-04-11
In the standard library in Rust before 1.50.0, read_to_end() does not validate the return value from Read in an unsafe context. This bug could lead to a buffer overflow.
CVE-2021-28876
PUBLISHED: 2021-04-11
In the standard library in Rust before 1.52.0, the Zip implementation has a panic safety issue. It calls __iterator_get_unchecked() more than once for the same index when the underlying iterator panics (in certain conditions). This bug could lead to a memory safety violation due to an unmet safety r...