This article is part of an ongoing series on privacy program metrics and benchmarking for incident response management, brought to you by Radar. Find earlier installments of this series here.
In last month’s benchmarking article, I wrote about the nostalgia of looking back on the previous year and how much preparing for the May 25, 2018, effective date of the EU General Data Protection Regulation dominates those memories. Preparing for the GDPR was a herculean effort for many. Now here we are, almost a year later, and the tide of GDPR fervor has ebbed, but not completely receded. And that’s to be expected — establishing and reinforcing a strong culture of compliance is not a “one-and-done” effort, but an ongoing and organization-wide push.
Organizations should already have most of the basic structures for compliance with GDPR in place — the ability to respond to data subject access requests, the extensive mapping and tracking of data that is processed, etcetera. But how are organizations responding to data breaches when they occur? And how are they making some of the critical determinations around if they need to provide notification, to whom, and when?
We will dive into the Radar's aggregated incident metadata to learn more about how organizations are complying with breach notification requirements under the GDPR. For benchmarking purposes, it’s important to note that the metadata available in the Radar platform is representative of organizations that use automation best practices to help them perform a consistent and objective multi-factor 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 and/or regulatory bodies. Without this type of system in place, your mileage may vary, and your risk of over and under notification is increased.
Making use of the “one-stop shop” under the GDPR
Last month, we discussed how, in the months following the May 25, 2018, effective date, a significant portion of incidents 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. To be precise, based on Radar's benchmarking data, 17% of incidents involving personal data required notification to authorities.
Now, let’s look further into which authorities were the recipient of these notifications.
Under the GDPR, there is a mechanism called the “one-stop shop” in which, as a rule, organizations with cross-border personal data processing activities only have to deal with one supervisory authority, called the lead supervisory authority, in the event that a data breach impacts data subjects in multiple member states of the EU. The lead supervisory authority is entrusted with coordinating investigation and entitled to involve other supervisory authorities in investigations.
Diving into the incident metadata, it seems that the use of the “one-stop shop” has been mixed. Some organizations choose to notify a lead supervisory authority, while others opt to notify each local supervisory authority (Radar allows the organization flexibility in making this designation). One reason we may not be seeing organizations take advantage of the one-stop-shop mechanism is the challenge in identifying the appropriate lead supervisory authority and associated reporting requirements.
As we see how organizations comply with the GDPR and how regulators enforce the rules or provide further guidance on the requirements, the use of the one-stop shop should become more prevalent. In its first annual report under the GDPR, the Irish Data Protection Commission revealed that of more than 3,542 data security breaches recorded, 136 cross-border processing complaints were received by the DPC through the one-stop-shop mechanism.
What the most common types of exposed data tell us about the expanding scope of privacy at a global scale
Coming from a U.S. state and federal privacy requirement lens, the GDPR introduced new ways of considering privacy concerns and raised the standard for stringency in privacy regulations. One area in which this is very apparent is the way the regulation has a very broad definition of personal data. Under U.S. state and federal laws, personal information is generally defined somewhat narrowly as an individual’s name in combination with a specified set of data elements, such as Social Security number. U.S. breach notification laws also view the risk of harm to individuals in terms of financial harm or identity theft.
Contrasting this point of view, the GDPR introduced a much broader definition of personal data, to mean any information in any form relating to an individual. This introduced consideration of sensitive information revealing cultural or reputational data otherwise unregulated in U.S. laws, such as race, ethnic origin, political opinions, religious or philosophical beliefs, etcetera. And under the GDPR, incident risk assessment of this data and the potential for risk of harm to individuals encompasses an evaluation of the risk to the rights and freedoms of affected individuals, not just financial harm or potential for identity theft.
When looking at the metadata for breaches under the GDPR in the months since its effective date, we see that the most common types of data exposed would be considered pretty mundane under U.S. laws. These include things like name, postal address, date of birth, email address, and nationality. Some of these data elements would be regulated under U.S. data breach notification regulations, but others would not be considered personal information as they are under the GDPR’s broad definition of the term.
Generally speaking, date of birth would not typically be considered highly sensitive data under most U.S. data breach regulations. Because U.S. state regulations vary from state to state, there are a few notables when it comes to regulating date of birth. For example, North Dakota regulates as personal information an individual’s first name or first initial and last name in combination with the individual’s date of birth. In Wyoming, interestingly, date of birth is not expressly regulated, but the first name or first initial and last name of a person in combination with a birth or marriage certificate is considered personal information. This is an eccentricity of the patchwork of U.S. state regulations, that the same data might be considered personal information in one jurisdiction or another, but always in the context of being in combination with a name.
All that to say, U.S. privacy professionals working for compliance with the GDPR are having to broaden the scope of their privacy programs to account for this wide definition of personal information.
GDPR moving forward: Where do we go from here?
When I think about next year and what I’ll remember most from this time, the GDPR remains a strong influence — though in new ways. Most prominent, perhaps, is the lasting impact of the GDPR’s influence on new regulations. The scope of the regulation effectively set the high-water mark for future privacy efforts, and the effects can be seen in regulations that have since cropped up.
Canada’s Personal Information Protection and Electronic Documents Act, which went into effect Nov. 1 of last year, was drafted expressly with the intent of aligning with the requirements of the GDPR in an attempt to harmonize with the regulation. Australia’s amendment to the Privacy Act 1988 established mandatory notification for data breaches and echoes many of the requirements under the GDPR, including the broad definition of personal information and the inclusion of sensitive data pertaining to racial or ethnic origins, political opinions, religious or philosophical beliefs, trade union membership, sex life or sexual orientation, and criminal record. And of course, there’s the California Consumer Privacy Act, sometimes nicknamed the “mini-GDPR,” which continues to push the depth and coverage of privacy regulations within the U.S.
They say what doesn’t kill you makes you stronger — and I think any privacy professional who made it through the GDPR’s effective date can relate to that sentiment. Our privacy programs are stronger having weathered the impacts of the GDPR, and we are better equipped for compliance with new, more rigorous regulations as a result. But it’s also important to remember that implementing privacy best practices and leveraging purpose-built automation technologies is a long-term effort, and steady, incremental improvements to processes are the name of the game.
That’s why it’s important, whenever you’re challenged with a new regulation, to return to the basics of proper risk assessment, mitigation and consistent, timely and well-documented response to data incidents and breaches as they occur.
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. The incident metadata available in the Radar platform is representative of organizations that use automation best practices 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 and/or regulatory bodies. Radar ensures that the incident metadata we analyze is in compliance with the Radar privacy statement, terms of use, and customer agreements.