by David William Silva, PhD
This is the third article of a series of four about the General Data Protection Regulation (GDPR) basics. In the first article, we covered context, motivations, and goals. In the second article, we reviewed terminology and basic definitions. In this third article, we discuss examples and applications of some of the main building blocks of GDPR.
Default Prohibitions and Non-Applicability of the Regulation
In our first article, we remarked that the “Regulation is all about protecting people, their privacy, their right to privacy, their right to own and protect their data, to choose what can be shared and with who, in which conditions, for how long, and to which extent.” It is also well-known that the Regulation is feared by many as it is recognized as “the world’s strictest security and privacy law.” However, in almost every section of the GDPR text, virtually all restrictions are followed by some form of exception that describes the context in which a particular data processing prohibited by default can be allowed, which means that under certain conditions, the prohibitions introduced by the Regulation shall not apply. This can be seen as a statement that while protecting natural persons and their rights, the Regulation also acknowledges the reality that organizations need data to function properly.
In the remainder of this article, we will highlight the cases and conditions where the Regulation shall not be applied, therefore releasing organizations of any risk of privacy violation and associated fines.
In order to highlight how GDPR rules can affect an organization’s operation, we must observe the practical difference between the two main classifications of data. As we discussed in the previous article and according to Article 4 of GDPR, personal data means any information related to an identified (directly or indirectly) or identifiable natural person, also known as a data subject, via identifiers such as name, identification number, location data, IP address, etc.
According to Recital 51, personal data can be further categorized as sensitive personal data concerning fundamental rights and freedoms. Personal data is considered a key issue in the GDPR law, in which sensitive personal data is labeled as the most important of all special categories of personal data, including genetic, biometric, and health data, as well as racial or ethnic origin, political opinions, religious or ideological convictions or trade union membership. Article 9 states that the processing of sensitive personal data shall be prohibited, including data concerning a natural person’s sex life or sexual orientation.
Article 9 presents a list of conditions through which the above does not apply. The number one is if the data subject has given explicit consent to processing their personal data for one or more specific purposes.
In some parts of the world, a data subject might be exposed to verbal and physical assaults (and in some cases even risk of death) if information regarding their sexual activities and/or sexual orientation is accessed and processed without consent. In many places in the world, the political and ideological views of an individual, which can often be directly or indirectly inferred by the individual’s habits such as shopping, entertainment, and other things, can also lead to all sorts of discrimination and other prejudicial actions. Some organizations might unlawfully calibrate their decisions towards their audience based on information related to race and ethnicity. The Regulation is very aware of all of these risks and therefore imposes requirements for preventing violations of a natural person’s rights and freedoms, as well as defines severe penalties for those who, for any reason, violate these requirements.
Data Protection Officer
The GDPR establishes that, regardless of its size, an organization might be obligated to appoint a Data Protection Officer (DPO) if the data processing is essential to achieving its goals. A DPO can be internal (an employee) or external. If an organization chooses to elect an employee as their DPO, they must ensure that the employee is not subject to conflict of interest (e.g., supervising themselves). The DPO must enforce the Regulation towards the organization’s compliance, and it cannot be dismissed or penalized as a result of the fulfillment of their tasks. Regardless of the motive, not appointing a DPO is an infringement subject to fines if an organization is found legally obliged to do so.
If a DPO is an employee, it might be better to be someone exclusively acting as a DPO. If an organization chooses the IT manager or someone in HR to fulfill this role, this might cause a conflict of interests and, therefore, defeats a DPO’s purpose.
Two mechanisms can serve as enablers of lawful data processing under certain conditions when it comes to data protection. The first one provides two-fold benefits: it serves the data subject’s interests with respect to their privacy while they can release organizations from provisions in the Regulation. The first one is anonymization. Recital 26 presents principles of data protection applied to any information related to an identified or identifiable natural person, which does not apply to anonymous data. In other words, personal data that is anonymized is exempt from the requirements of GDPR.
Anonymization is described as a process that produces information that no longer relates to an identified or identifiable natural person. Therefore, it is an interesting mechanism since the Regulation allows the general processing of this type of data.
A corollary of the above is that any other mechanism that undeniably produces information no longer related to an identified or identifiable natural person enables the same benefits associated with anonymized data.
The second data protection mechanism is pseudonymization. Article 4 describes pseudonymization as the process that produces information that can no longer identify a natural person without considering additional information. Pseudonymization is allowed by the GDPR as long as such additional information is kept and handled separately and subject to security and administrative measures to prevent the re-identification of a natural person.
The main distinction between anonymization and pseudonymization is that the likelihood of re-identification is higher in the case of pseudonymization.
Trivial techniques for anonymization and pseudonymization might not provide the results one would expect from data protection mechanisms. It is not new that anonymized information can be “deanonymized.” In fact, some schemes for deanonymization have been available since the late 2000s. Depending on the data type, it is possible to derive deanonymization attacks for a particular niche.
When it comes to security and privacy measures, the GDPR recommends controllers choose methods to secure personal data, among other aspects, those considered the state of the art.
Data Protection Impact Assessment
Data processing can be performed in many different ways. Sometimes it might involve standard procedures within well-known scenarios. The risks and benefits are known in these cases, and further analysis before data processing might not be needed. In other cases, data processing can involve new technologies applied in contexts and for purposes that have not yet been comprehensively vetted or even properly understood. In these cases, the controller, advised by the DPO, shall execute a data protection impact assessment before the data processing, where a single assessment may address many similar operations, each of which similarly presents high risks. Article 35 states that an impact assessment is required when data processing has legal effects and when monitoring a publicly accessible area on a large scale.
With respect to qualifying data processing, a data protection impact assessment shall include:
- At least a description of the involved operations.
- An assessment of the needs and purposes of each operation.
- An assessment of the risks to the rights and freedoms of data subjects induced by each operation.
- The measures to mitigate the risks.
Data Protection by Design and by Default
Conducting an assessment risk prior to any new data processing routine is undoubtedly recommended for any organization working towards GDPR compliance. However, it might not be enough. Article 25 establishes the notion of data protection by default and by design within the scope of GDPR. This notion involves executing assessments and data protection measures while designing and developing data processing operations. This approach greatly increases the chances of an organization meeting the GDPR requirements.
An organization that implements data protection by design and by default may advertise self-proclaimed compliance with this notion or, as provisioned in Article 42, voluntarily subject to a third-party transparent certification process.
Article 4 defines a personal data breach as “a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data transmitted, stored or otherwise processed.” Data breaches must be notified no later than 72 hours after their detection to the supervisory authority and the data subject without delay if the breach is likely to impose risks to the rights and freedoms of natural persons.
Unlike what many people think, not all data breaches result from a sophisticated cyberattack. With many companies currently adopting the “bring your own device” culture, data breaches might occur if an employee loses a device (external drive, phone, laptop, etc.). Suppose an organization does not have a policy for disposing of documents. In that case, it might be a target of an attack known as dumpster diving, which can lead to unauthorized access to data under the protection of GDPR.
Among other duties, the DPO must work to increase security and privacy awareness, educate the members of the organization they are working for, and ensure that the required procedures are being observed. Unintentional actions of apparent harmless nature can cause severe damage to someone’s rights and freedoms. This can happen with an email containing sensitive information sent to the wrong recipient and/or a text message sent to a group of people which exposes the association of those people with matters that were supposed to be kept private.
What might not be apparent to the casual observer is that the processing of personal data is generally prohibited, with two exceptions: 1) when it is expressly allowed by law, and 2) the data subject has consented to the processing. However, consent is one of the six bases for processing personal data. Besides consent, the GDPR also allows contract, legal obligations, vital interests of the data subject, public interest, and legitimate interest.
One of the most common ways of obtaining consent is via web forms that request the user to opt-in for receiving marketing-related information, which is typically optional. However, some services will require the user to agree to the organization’s terms and services and privacy policies to proceed (where proceeding could mean signing up to a web service, as an example).
GDPR and IAM
Biometric data is sensitive data. If biometric data is required for the purpose of authentication, consent must be requested for that purpose and nothing more. The same applies to other “what you are” types of information, as much as they don’t sound as risky as others, such as behavior patterns. Sensitive data can be in the form of physical data (such as personal information in ID cards, physical documents, certificates, etc.) or digital data (videos, audio, images, etc.). These are often used for various authentication procedures that leverage multiple different factors.
Even if used for security purposes, consent for processing sensitive information must be requested. If the processing occurs in the data subject’s vital interests, GDPR allows its processing. Any organization unsure about what qualifies as “vital” should not assume compliance and avoid potential Regulation violations.
Some authentication techniques analyze images of the user. Each organization must review the type of data being used, for what purpose, and the associated provisions in the Regulation. For instance, GDPR distinguishes the processing of different types of personal data. Recital 51 states that “The processing of photographs should not systematically be considered to be processing of special categories of personal data as they are covered by the definition of biometric data only when processed through a specific technical means allowing the unique identification or authentication of a natural person.”
IAM plays multiple roles with respect to data privacy. In order to use personal and sensitive data from a user for authentication and authorization purposes, consent must be given from that user for the particular purpose expressed in the consent request. Once consent is given and personal and sensitive data are collected, IAM mechanisms can be used to protect access to that data.
DPOs can request the implementation of IAM policies, methodologies, tools, and procedures to prevent violations caused by negligent behavior, bad practices, ignorance, and malicious activities that might occur. In particular, strong IAM measures can prevent intentional and even accidental data breaches (such as those mentioned previously.) An organization can refer to its IAM framework as part of providing evidence of GDPR compliance. User authentication is one component of the “privacy by design” notion. Recital 57 presents procedures for receiving additional data for identification purposes, which must be used to support the exercise of the data subject’s rights.
Even breaking down an overview of GDPR into four articles and dedicating one to examples and applications, it is virtually impossible to cover all (or any reasonably large amount of) examples and applications. In this article, we initiated a conversation about connecting some highlights of the GDPR text and associated concepts with their practical applications. An organization seeking compliance with the Regulation should take advantage of key points discussed in this article, such as exploring data processing over data that cannot identify data subjects, embracing the “data protection by default and by design” approach, properly requesting consent whenever the processing of personal data is needed, properly establishing a DPO, undergoing an external certification, and using IAM as one of the key GDPR compliance enablers.
About the Author
David William Silva is a Senior Research Scientist at Symetrix Corporation and Algemetric and is responsible for the research and development of innovative products related to security, privacy, and efficient computation powered by applied mathematics. David started his career as a Software Engineer focused on web services and agile software development, which led him to be involved with several projects from startups to government and large corporations. After 17 years of conducting R&D in Brazil, David moved to the US to engage in scientific research applied to a global industry of security and privacy, which has been his focus for the past seven years.
IDPro is a professional organization for practitioners of Identity and Access Management
Great last keynote on the Metaverse and the challenges ahead with digital identity
Such a fun panel with @dgwbirch of @chyppings, @heathervescent of @idpro_org, @JonnyHowle of @discoxyz, Gopal Padinjaruveetil of @AAANews, and @katrynadow of @meeco_me
It's the last day of #Identiverse! It's been a really exciting experience so far and we're looking forward to the last day of sessions and activities. What's your biggest @Identiverse 2022 takeaway? Let us know in the comments! #IDProatIDV
Love @LancePeterman’s idea of expanding the pool of talent that #identity can tap into by (guerrilla) sneaking identity courses into other majors.
(Though I think we have enough PoliSci majors already 😏)
#identiverse #Identiverse2022 @idpro_org
Time for (short-timer) @idpro_org Board Member @LancePeterman to share his thoughts on how we can create the next gen of identity professionals #identiverse