This article is part of an ongoing series on privacy program metrics and benchmarking for incident response management, brought to you by RADAR. Read the original article on the IAPP Privacy Advisor.
Do you find yourself thinking about what you were doing this time last year? Maybe it’s the prevalence of social media and the memories that show up in our feeds like our own personal versions of “this day in history,” but in any case, when I think about this time last year, I think about the EU General Data Protection Regulation. In the months leading up to the GDPR’s May 25, 2018, effective date, a type of frenzy took over.
While some organizations were on track in their preparations, still many more were struggling every day leading up to the effective date to make their preparations. The stakes were high. Rhetoric at the time was that the GDPR was a game-changer, that the notification obligations were stringent, the consequences of failure to provide notice were severe, and on top of all that, the issue of GDPR preparedness was gaining visibility at the board level.
Here we are, a year later. Do we know how compliance with the GDPR has impacted our work or our organizations?
For this month’s benchmarking article, we will begin a two-part look into GDPR data breach notification benchmarking data, starting with the big question: At what rate are organizations providing notification?
Companies providing notification to supervisory authorities and individuals under GDPR
Before diving into the RADAR’s aggregated metadata, let’s set some context. For benchmarking purposes, it’s important to note that the metadata available in the RADAR platform is representative of organizations that use automation to help them perform a consistent and objective multifactor incident risk assessment using a methodology that incorporates incident-specific risk factors (sensitivity of the data involved and severity of the incident) to determine if the incident is a data breach requiring notification to individuals or regulatory bodies. Organizations using purpose-built automation and best practices are able to streamline and operationalize their data breach response — all that to say that, without this type of system in place, your mileage may vary.
With that out of the way, what we see in the RADAR metadata from May 25, 2018, to present day is that a significant portion of incidents (83 percent) involving personal data can and should be sufficiently risk mitigated to keep them from hitting the risk or high-risk threshold for notification under the GDPR. Given the presumption of a breach, you must prove this with a well-documented and consistent multifactor risk assessment of these all these incidents, of course. That leaves 17 percent of incidents involving personal data that will likely rise to the level where they require notification to authorities. Breaking that figure down further into the two tiers of risk as defined under the GDPR, about 4 percent fell into the category of elevated risk, requiring only notification to regulators, while the remaining 13 percent were considered high risk and required notification to both regulators and individuals (more on that distinction in the section below).
Understanding the required risk of harm analysis under GDPR, from a US perspective
When looking at the data breaches that require notification under the GDPR, it’s important to thoroughly understand how the regulation defines harm.
Privacy professionals working in the U.S. are used to a patchwork of various state and federal breach notification regulations, each regulation with its own unique thresholds for determining the risk of harm to individuals, as well as different exceptions or exemptions when it comes to providing notification to regulators or affected individuals. While both U.S. laws and the GDPR require an assessment of the risk of harm, U.S. law, when specified, defines risk of harm as risk of financial harm or identity theft, whereas the GDPR standard for assessing risk of harm has two tiers:
- Risk: A breach that is likely to result in risk to the rights and freedoms of natural persons. This type of breach requires notification be provided to supervisory authorities.
- High Risk: A breach that is likely to result in a high risk to the rights and freedoms of natural persons. This type of breach requires notification be provided to supervisory authorities and data subjects.
Furthermore, it’s important for privacy professionals working within the U.S. to understand the differences in how U.S. state and federal laws allow for exceptions in comparison to the GDPR. U.S. breach notification laws generally provide for an exception from notification. For example, U.S. state laws offer such exceptions when data is encrypted and the encryption key is not compromised or if the incident involves paper records and the law does not regulate paper.
Under the GDPR, encryption (a form of pseudonymization) may be considered an appropriate technical protection measure when assessing risk of data confidentiality and integrity breach but may not be sufficient if assessing the risk of a data availability breach. Consequently, encryption is not considered an exception from notification as it is under most U.S. laws. Under the GDPR, only anonymized data could be considered analogous to an exception. If data is anonymized, the data subject cannot be identified, which removes the data from the scope of the GDPR.
Given the above, U.S. privacy professionals can begin to put the figure presented from RADAR metadata into context. With a tiered approach to evaluating the potential risk of harm to impacted data subjects and the absence of permissible exceptions to providing notification, the GDPR may appear to invite a flood of notifications, but that doesn’t have to be so, as our metadata proves, if you follow best practices in implementing automated multifactor risk assessment to ensure consistency and objectivity of your incident risk scoring and decision making.
Not so fast: GDPR and over-notification
In the months following the GDPR’s effective date, it became common knowledge that over-reporting presented a problem for supervisory authorities under the GDPR. Deputy Information Commissioner James Dipple-Johnstone, from the Information Commissioner’s Office, revealed during a cybersecurity conference in September 2018 that the ICO had received 500 reports by telephone per week since the GDPR went into force — and estimated that a third of those reports were unnecessary or failed to meet the threshold for a data incident. Dipple-Johnstone went on to explain that this over-reporting of breaches could be an attempt to be transparent or could be a result of misunderstanding the regulation. And just recently at the IAPP’s Data Protection Intensive: U.K., Stephen Eckersley, director of investigations at the ICO, stated that the number of reported breaches has leveled out to 380 to 400 per month — a significant volume.
So what’s the problem with over-reporting data breaches?
Over-reporting is not a strategy. It draws the attention of the regulator, as it shows that you don’t have a good risk assessment process in place. Both the ICO and France’s CNIL have encouraged thoughtful consideration when making the decision to report data breaches under the GDPR, and the ICO has specifically reminded organizations that not all data breaches need to be reported. Dipple-Johnstone echoed this sentiment, with the reassurance that “the ICO does not seek perfection even if to some it may feel like that. We seek evidence of senior management and board level insight and accountability. We seek evidence of systems that provide a robust level of protection and privacy.”
Over-reporting can also needlessly put your organization’s reputation at risk. In a recent Law360 article, Jon Baines, data protection advisor at Mishcon de Reya, gave this real-world example of the risk of over-reporting:
“Let’s say you’ve been very overzealous and reported 20 minor breaches to the ICO. If someone makes a freedom-of-information request and they find themselves compelled to disclose that, that’s potentially going to affect your reputation and you’re going to affect your share price.”
Moving forward: GDPR and beyond
A year ago, many were working toward the May 25 GDPR effective date as if it were a deadline. In reality, this was just the first day of a new world order. Our collective efforts to remain compliant and protect the sensitive data we are entrusted stretches before us, as does the challenge to continually measure and improve upon our privacy programs.
Evaluate every incident involving personal data based on its level of risk based on the risk factors involved when calculating that risk. Bring consistency and objectivity into the process to avoid over-reporting or underreporting, and benchmark the results to identify key areas for improvement in that process. Run your privacy program so that, when you’re looking back a year from today, you’re proud of the work you have done.
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.