This article is part of an ongoing series on privacy program metrics and benchmarking for incident response management, brought to you by RADAR, Inc., a provider of purpose-built decision-support software designed to guide users through a consistent, defensible process for incident management and risk assessment. Find earlier installments of this series here.

When we look at benchmarking metrics for our privacy and incident response programs, it’s easy to focus on the trends that emerge: What are the majority doing on data breach notification? What is the mainstream response-time, say, or typical breakdown of incidents that are malicious — versus unintentional — in nature? Metrics are a powerful tool in measuring one’s performance, and benchmarking metrics allow for comparing one’s performance to those of peers. It makes sense that a lot of our attention is therefore drawn to metrics that are commonly measured by most organizations.

This isn’t to say, however, that lessons cannot be learned in examining the fringe cases and what happens infrequently in your incident response program. These data points can speak volumes to the culture of privacy within an organization, whether that be the fact that a low volume exists or as a red flag that something needs to be looked into, explained or tracked to see if it foretells of an emerging trend.

With this in mind, we’re going to dive into a relatively infrequent occurrence in privacy programs: The decision to provide voluntary notification of a data breach.

Voluntarily providing notification of a data breach 

When deciding if an incident requires notification to affected individuals and regulators, there are certain risk factors you take into account: What data was exposed? What was the nature of the incident? What is required, per the letter of the regulation, when it comes to determining the potential risk of harm to individuals?

This is a multi-factor risk assessment that takes into account the severity of an incident and sensitivity of the personal data in determining the likelihood of harm to the individual,  resulting in a decision to notify — or not— regulatory bodies and affected individuals.

When we talk about voluntary notification, these are incidents that have been risk assessed, and the results indicate that the threshold for notification was not met. So while notification is not required as outlined by the regulatory threshold, an organization may decide to provide notice to affected individuals anyway.

How common is this? RADAR metadata indicates that some organizations do in fact choose to provide voluntary notification. In all the incidents risk assessed in 2017 and the first half of 2018, 3 percent of cases resulted in the organization choosing to voluntarily notify.

Why would an organization elect to provide voluntary notification of an incident?

The decision to provide voluntary notification is largely indicative of the internal policies and culture within an organization. The desire to apply decisions consistently across multiple jurisdictions is one example situation that may result in an organization electing to provide notification when it is not required.

For example, say an incident involves multiple jurisdictions, spanning several U.S. states, each with different breach notification regulations. In some states, the details of the incident meet the threshold of harm so that notification is required.

In other states, notification is not required due to an exception within the state’s regulation or differences in the definition of protected data. Organizations in this instance may elect to voluntarily notify, based on policies set and their culture of compliance. This also avoids potential public relations issues in the future: How do you explain to regulators, or the public, that the same incident warranted telling certain state residents but not others?

Voluntary notification and the regulation of paper data

This example became more relatable when we further broke down the metadata on voluntary notifications by incident category: paper or electronic. The rate of voluntary notification involving paper incidents is four times more common than electronic incidents in 2017 and is tracking to remain at that ratio in 2018.

Paper data breaches are more common for organizations to voluntarily notify. One reason for this could be that paper records are only regulated in some states, and organizations are deciding to notify uniformly across all impacted jurisdictions and ignoring paper exceptions in some to avoid any backlash from impacted individuals who could submit complaints to their state attorney general.

Required for notification decision-making? Strong and consistent risk assessment

There are many steps involved when it comes to the decision to provide voluntary notification. First, you must have a consistent incident risk assessment process that takes into account key risk and risk-mitigation factors and helps you determine, based on the most up-to-date regulations, what your obligations are in each applicable jurisdiction. This process provides consistency in your multi-factor risk assessment as proof that the notification was not mandated, so you can provide credible evidence of your strong culture of customer privacy and compliance in electing to notify.

Second to an objective and consistent risk assessment, you also need to allow in your process the flexibility to document that notification wasn’t required, but that you’ve provided it anyway, and why. This type of “show your work” record-keeping in designating these incident notifications as voluntary can be good from an auditing perspective, so make sure you categorize these incidents properly.

While the decision to provide voluntary notification may be infrequent, there are reasons beyond the letter of the law organizations may elect to do so. And when they do, it’s important that these organizations are making classifying these notifications in accordance with their privacy policies and culture of compliance, are documenting the process along the way, and always take into account the most up-to-date regulatory requirements.

About the data used in this series: Information extracted from RADAR for purposes of statistical analysis is aggregated metadata that is not identifiable to any customer or data subject. RADAR ensures that the incident metadata we analyze is in compliance with the RADAR privacy statement,terms of use, and customer agreements.