Atlassian Blog

We read 100 data breach notifications to make this guide (which we hope you’ll never need)

Nothing fills out the “worst-case scenario” column quite like a data breach. For the countless teams out there who work hard to protect their customers’ data, the idea of compromising that trust is a nightmare.

Data breaches are on a lot of minds lately with the 2017 Equifax data breach, which exposed personal data from 143 million American consumers. The company, security industry, and regulators have a huge task of working out the details on how something like this happens.

At Statuspage, we talk a lot about transparency, trust, and letting the right people know when things go wrong. Transparency around crises is a core part of our philosophy here at Atlassian and Statuspage. While we’re typically talking about these thing in relation to outages and downtime instead of data breaches, there are a lot of overlapping themes. The benchmarks of a great downtime response strategy aren’t all that different from a great data breach response strategy. We fancy ourselves experts at incident response best practices, we figured it would be interesting to take a look at data breach response best practices and see where we can notice some overlap.

A brief look at incident response vs. data breach response

For the most part, downtime is more tolerable and less troubling than a data breach. A few minutes of an unscheduled outage is usually more palatable than even a hint of a data breach. Teams will even purposefully take their service offline to prevent a breach from spreading in some cases. Because of this, most systems are built to prioritize data safety over perfect uptime. We’ve talked plenty about how downtime is inevitable and shooting for 100% uptime shouldn’t be the goal. That’s partly because 100% data protection should be the goal. Think about it. Would you rather your bank’s mobile app went down for a day or lost your transaction history for a day? It’s pretty clear that in the web service hierarchy of needs, data protection trumps uptime. And that’s OK.

Because of the heightened sensitivity to data, we see a lot more regulatory activity around data breaches. Regulators mostly leave it up to organizations on how they’ll announce downtime and service interruptions. But they have a lot to say, understandably so, about how teams should respond to data breaches.

Data breach response regulatory summary (slightly less boring than it sounds)

The Equifax breach has a lot of folks calling for updates to how regulators patrol breach response. Although there are varying opinion on whether the current rules go far enough, it’s worth taking stock of where things stand now.

From Vox:

Right now, there is little national oversight on how companies handle data privacy. When it comes to notifying consumers that their data has been stolen, laws vary state to state and differ in how much time and how much information companies are required to divulge. Equifax is based in Georgia, a state where there is no timeline specified for when a company must notify customers about a breach.

California’s law, enacted in 2002, was the first in the country and became the template for most other states whose lawmakers adopted similar regulations. The main paragraph of California’s law is here (note: if you’re like us and the legal-ese makes your brain hurt, fear not, we break it down in plain English in the next section).

“(a) Any agency that owns or licenses computerized data that includes personal information shall disclose any breach of the security of the system following discovery or notification of the breach in the security of the data to any resident of California (1) whose unencrypted personal information was, or is reasonably believed to have been, acquired by an unauthorized person, or, (2) whose encrypted personal information was, or is reasonably believed to have been, acquired by an unauthorized person and the encryption key or security credential was, or is reasonably believed to have been, acquired by an unauthorized person and the agency that owns or licenses the encrypted information has a reasonable belief that the encryption key or security credential could render that personal information readable or useable. The disclosure shall be made in the most expedient time possible and without unreasonable delay, consistent with the legitimate needs of law enforcement, as provided in subdivision (c), or any measures necessary to determine the scope of the breach and restore the reasonable integrity of the data system.”

Now, in English:

Who this applies to? Any person or group who owns or licenses computerized data that includes personal information.

Which has undergone what? Any breach of the security of the system.

Has to do what? Disclose the breach to any resident of California whose unencrypted personal information was, or is reasonably believed to have been, acquired by an unauthorized person. The same applies if this is encrypted information if there is a known or reasonable belief that the encryption key was also compromised. Basically, if there’s any sort of proof — or reasonable belief — that someone unauthorized was ever able to view private info, they need to notify them.

By when? The most expedient time possible and without unreasonable delay. By now you should be working with law enforcement, who may advise you on when to send the announcement.

Sounds simple enough. But how do these notifications need to be sent? And what should they say? Thankfully, the legislation includes a template which advises the following information be included:

It’s important that these are the regulations for California. While other states drew inspiration from these guidelines, it’s worth noting that these change for users in different states and countries. Please do your own research and contact your own experts and lawyers if you need to put any of this into practice.

The research: 100 breach notifications

Now that we have a handle on what constitutes a breach and what a breach response looks like, let’s have a look at how organizations approach these announcements.

To get a better idea of how teams draft these response letters, we downloaded 100 of the most recent sample responses that were filed recently with the State of California. Filed breach response samples are public record and posted on the state’s Department of Justice website.

Reading these hundreds of pages of breach notification was eye-opening (and a little eye-straining). It’s surprising how much good breach response measures have in common with incident response strategies. It’s also interesting how much variety there was in both the type of organization affected (hospitals, hotels, insurance companies, law offices) and the catalyst of the breach (phishing scams, lost devices, break-ins).

In no particular order, here are a handful of our observations from this research:

Closing thoughts

Obviously this is a complicated topic, and you should talk to real experts if a data breach happens to your company. It’s important let the lawyers and law enforcement do their jobs.

If you’re interested in learning more, here are some helpful links:

As people trust cloud companies to keep more and more of their info online, it’s going to be easy to take that trust for granted. Just like smart incident communication, smart data breach communication means putting yourself in the customer’s shoes. It’s about trying to make the best experience possible for the customer. Even if it’s a worst-case scenario kind of day.