When is a Data Breach Really Considered a Data Breach in the USA?

Aidan Simister
| Time 4 min read| Published On - March 21, 2018

Here at Lepide we talk a lot about how we help companies identify and prevent data leakage and how we can help mitigate the risks of data breaches. However, it’s not always clear as to what constitutes a breach in real world terms.

At what point is a breach technically a breach (i.e. what conditions need to be met before you are liable to disclose)?

In the USA, definitions vary from state to state and differ considerably depending on where the breach occurred.

What Classifies as Personally Identifiable Information?

Across most of the states in the USA, for data to be considered under ‘data breach’ rules, the ‘breach’ will likely contain a combination of first name, surname, SSN, formal/state ID details (such as passport information), drivers’ licence details and more (including any nationally recognised forms of ID). It also includes any personal banking information; such as account numbers, sort codes or anything that could potentially grant access to banking facilities, including usernames or passwords.

However, this does differ from state to state. For example, in Texas, South Dakota, Alabama and Utah there is no requirement to disclose a breach of social security number, state ID or financial account information.

One of the key challenges preventing breaches of this sort is that individuals rarely assign unique passwords for multiple accounts. It’s far more common for users to take one password and use it for multiple services/accounts. If passwords fall into the wrong hands, the damage could be potentially significant.

What About the Healthcare Sector?

You are obliged to disclose information pertaining to breached patient medical history if your organization is located in Oregon, Nevada, California, Montana, Nevada, Missouri, Illinois, Arizona or Florida.

We were talking to one of our healthcare customers in Wisconsin last week, and they reside in the only state that consider DNA to be considered as being personal information (PII). In other words, if your DNA details were breached, there is no obligation for healthcare providers to disclose this unless it happens in Wisconsin. Information around healthcare providers or insurers (different to patient information) has wider coverage within Oregon, California, North Dakota, Montana, Illinois and Florida, all noting this as worthy of disclosure.

Other Notable Data Breach Exceptions

Across all sectors, only in North Dakota do you need to disclose a breach of Employer ID, and only Texas is date of birth considered to be liable for disclosure. However, both these states require you to disclose a breach of Mothers Maiden Name. North Dakota and Washington are also the only states that require disclosure if the breach contains Tax information.

What this Means for Data Breaches

My view is that we probably need to tighten up definitions and disclosure rules. If my DNA was leaked, I’d like to know about it, wouldn’t you? Likewise, given the prevalence of Tax ID for authentication (such as logging on to online banking), I would have thought this would be more universal.

It’s about the principal of the breach more than anything. It’s not necessarily about what is leaked so much as the fact a leak occurred. If an organisation experiences a data breach, to me that signals a lack of preparation with compliance and security regulations, and a disregard for the sensitive nature of my Personally Identifiable Information (although, of course, there are exceptions to this).

Whatever the cause of the breach, and whatever information is leaked, should we not have the right to know if we were involved? Breach definition and regulation needs to be simplified. The simpler it is, the more universal the regulation becomes, and the better chance there is of breaches being properly handled, disclosed and reported.

Aidan Simister

Aidan Simister

Having worked in the IT industry for a little over 22 years in various capacities, Aidan is a veteran in the field. Specifically, Aidan knows how to build global teams for security and compliance vendors, often from a standing start. After joining Lepide in 2015, Aidan has helped contribute to the accelerated growth in the US and European markets.

Popular Blog Posts