Defining a Winning GDPR Strategy Part 3: Identity and Access Management to the Rescue
- By Sagara Gunathunga
- 14 Feb, 2018
About this series
This 4 part series aims to provide comprehensive insights on GDPR and practical guidelines for business organizations to plan, define, and execute a successful GDPR compliance strategy.
Read Part 1 - Introduction to GDPR
Read Part 2 - 7 Steps for GDPR Compliance
Read Part 4 - GDPR Compliant Consent Design
Traditionally Identity and Access Management (IAM) is used by organizations to digitally manage identities (such as those of an organization's employees and customers of a business) and access to resources managed by them. With the privacy standard enforced by GDPR, an IAM tool has to broaden its scope by supporting an organization to implement the privacy standard and individual rights.
Although we generally use the term IAM, most of the concepts discussed here are common for specialized branches of IAM such as workforce-IAM and Customer-IAM. This article will look at several features supported by IAM products:
- Centralized Identity Management
- Privacy by Design (PbD)
- Anonymization and Pseudonymization
- Facilitate to exercise individual rights
- Consent Management
Centralized Identity Management
Any business or organization today did not exist in its current form when it started, none of these organizations will remain unchanged in a decade. The same is reflected in an organization’s software system as well. Originally an organization may have developed or purchased a system for proposed project. As business operations evolves, the organization may have to purchase/implement other software systems - in most cases identity or user data such as user name, their credentials, and profile data. These are scattered and duplicated in multiple systems and a typical example is illustrated in the following diagram:
When applying privacy standards enforced by a regulation such as GDPR, an organization has to modify and continuously maintain all systems containing identity data. This in turn will greatly increase operational costs and utilize a significant portion of the IT budget. Few decades ago, most of the systems in an organization were deployed on-premise. Yet today, with the success of cloud-based service offerings, some level of identity data need to be stored in these cloud services where an organization does not have much control on data storage, network systems etc. This further increases privacy risks.
As a solution to this situation, organizations can introduce IAM system to centrally manage identities, identity profiles, and all other systems communicating with the IAM system to fulfil IAM requirements such as authentication, authorization, user profile, and preference management. In technical terms, the IAM system acts as the ‘Identity Provider (IdP)’ for other systems and the IAM system considers other system as the ‘Service Providers (SP)’. This is illustrated in the following diagram:
The above discussed architecture can be applied to and works well for both on-premise and cloud services. For example when an employee tries to login to the cloud service, it can redirect the user to organizational level IdP for authentication. The cloud service can trust and operate on ‘Secure Token’ issued by the organizational level IdP after successful authentication and authorization. Security Assertion Markup Language (SAML) and OpenID Connect are some of the most widely used protocols to communicate IdP and SPs to share identity data securely. Furthermore, modern standards such as OAuth2 and User Managed Access (UMA) can be used for access delegations and access management without compromising security and privacy.
Privacy by Design (PbD)
Prior to discussing the ‘Privacy by Design’ concept, I’d like to provide an understanding of the exact problem which this concept solves. Dr. Ann Cavoukian, a leading figure on privacy states: “In an organization, the majority of privacy breaches remain unchallenged, unregulated, and unknown.”* Together with IPC (Information and Privacy Commissioner of Ontario), she promoted the concept of ‘Privacy by Design’ with a framework of 7 principles. A very high-level overview of these principles are given below:
- Proactive not reactive, preventative not remedial - Anticipate, identify, and prevent privacy invasive events before they occur
- Privacy as the default setting - Build-in the maximum degree of privacy into the default settings for any system or business practice
- Privacy embedded into design - Embed privacy settings into the design and architecture of information technology systems and business practices instead of implementing them as add-ons
- Full functionality, positive-sum not zero-sum - Create a balance between privacy and security because it is possible to have both
- End-to-end security, full lifecycle protection - Embed strong security measures to the complete lifecycle of data to ensure secure management of the information from beginning to end
- Visibility and transparency, keep it open - Assure stakeholders that privacy standards are open and transparent
- Respect for user privacy, keep it user-centric - Protect the interests of users by offering strong privacy defaults, appropriate notice, and empowering user-friendly options
Most of the IAM tools available today are designed and built based on these ‘Privacy by Design’ principles and facilitate communication with other systems without violating these principles. On-boarding proper a IAM tool into the system architecture moves the overall system one step closer to achieving these design principles.
Anonymization and Pseudonymization
Anonymization and pseudonymisation are two distinct concepts (although some similarities exist). A brief introduction to these concepts are provided below:
Anonymization is the process of removing personally identifiable information from data sets. After anonymization, an individual is no longer identifiable based on the remaining data within the system.
Pseudonymization is the process of removing or replacing personally identifiable information from data sets through artificial identifiers. After pseudonymization, a particular individual is no longer identifiable without the use of additional information. In contrast to anonymization, through pseudonymization an individual can be uniquely identifiable using additional information - generally by mapping records generated during the initial pseudonymization process.
Generally out-of-the-box IAM tools support anonymization and pseudonymization. Hence, when on-boarding IAM systems organizations need not necessarily reinvent or maintain their own anonymization and pseudonymization mechanisms. In addition, in most cases where a new user is added to an IAM system, it generates a pseudonymous system ID for that particular user. Usually service providers or other systems use ID to refer to users whenever requirements arise. IAM systems can provide personally identifiable information (PII) in a transient manner.
Facilitate to exercise individual rights
GDPR defines a very strong set of individual rights where data processing organizations must facilitate and provide means to individuals whereby they can exercise those rights. The following diagram illustrates these rights (read Part 1 of this series for detailed explanations of these rights):
With GDPR compliance, the end user self-care portal feature of most IAM products will become an integral and very significant feature. Traditionally these self-care portals are used to manage user profiles by users themselves, and use cases such as associate or another account from the same user, associate with devices which are used in multi-factor authentication etc. However with GDPR compliance, these self-care portals can be used as a medium for individuals to exercise their individual rights provided in the GDPR regulation.
Some of these important rights and how they can be supported through the self-care portal are discussed below:
- The right of access - Individuals are able review what personal data is stored in the system and for what purposes this data is used for through the self-care portal. Enabling basic level accessibility via the self-care portal reduces operational costs for organizations and also reduces cost of having a separate system for responding to Subject Access Requests (SARs).
- The right to rectification - Individuals can review and rectify errors in personal data stored in the organization by themselves or they can lodge rectification requests through the self-care portal.
- The right to be forgotten - The self-care portal allows individuals to remove part of their profile, remove their user profile entirely (according to the organization’s policies), and lodge a “forget me” request easily.
- The right to restrict processing and the right to object - Individuals can make restrictions on some profile data or object some data processing operations through the self-care portal.
- The right to data portability - Individuals can download or request to download personal data stored in the organization in a standard format such as PDF, CSV, XML, or JSON through the self-care portal. Additionally, where possible individuals can request to auto provision user profiles to 3rd party systems trusted by the organization - most IAM products support provisioning standards such as SCIM and this is not a hard feature to support.
Consent and consent lifecycle management are very significant and well defined concepts of GDPR. A high level explanation of consent lifecycle management is provided below:
- Consent design - GDPR provides a detailed set of guidelines and rules for consent design. Basically each and every organization has to design consent pages according to their data processing operations and taking into considerations their targeted user base. For example, if the target use base is children, there are specific guidelines as defined by GDPR. (Part 4 of this series will discuss consent design guidelines and rules in a detailed manner).
- Capturing, storing, and managing consent - With the formalization of privacy standards such as GDPR, most IAM tools support full consent management. Usually before sharing any user profile data with another system, the identity provider has to get explicit consent from individuals. In addition, the system should store each consent with additional details such as timestamp, consented methodology, etc. Instead of building an in-house consent management system, it is highly advised to use consent management features available with IAM products.
- Review and revoke existing consent given by individuals - According to GDPR, organizations must facilitate individuals to review existing consent given by them and if required, request to revoke this consent. Self-care portal features discussed in the previous section can be used to cater to this requirement. By logging-in to the self-care portal, it’s possible for individuals to review and revoke their previously given consent.