Privacy By Design as a System Design Strategy: Part 2

Introduction

In the first part of this article series, we discussed opportunities and challenges that are common for any enterprise when dealing with privacy. We also discussed applying Privacy by Design (PbD) principle as a best practice instead of considering support for each privacy regulation as an orthogonal effort. In this article, we further discuss some other important practical aspects related to PbD principles.

Use Standard Security Protocols

Unlike some other technology areas, in security, we recommend using open and standard security protocols and frameworks as much as possible. This is mainly due to the fact that open standards are maintained to collaborate with a large number of parties. For instance, researchers all over the world are trying to break the latest encryption algorithms while other researchers are trying to develop more secure algorithms. In addition, when a vulnerability is detected, these communities act together to educate people and are eager to find remedies.

Furthermore, the use of open standards greatly enhances interoperability with other systems. This is a very significant advantage because nowadays it is rare to find a business system which operates in isolation and business to business integration via enterprise integration technologies is becoming more prominent.

Use On-demand PII Data Sharing

In the first article of this series, we discussed how to move PII data into a separate component and sharing this data with other components in an on-demand manner as a best practice. However, you may have wondered how we share data among these components and whether or not any standards exist. The answer is yes - there are several open standards available to cater to these requirements: SAML and OpenID Connect are two such widely used protocols.

Let’s discuss this matter using the following detailed example. Assume that the sales app requires the following PII data related to an employee named John. According to our solution, the sales app should send a request to the users and access managed component, which handles PII data, asking for the above data related to John. Then the users and access managed component sends a response message with the requested data.

Here is our solution based on SAML protocol: the sales app sends a SAML requests with required attribute names, then the users and access managed component verifies both the sale app and the user. If it’s successful, it will return a SAML response with requested attribute values.

Here’s a sample SAML Response message related to the above example:

Here is the same response message as the above example using OpenID Connect protocol instead of SAML:

It’s also important to mention here that you should not persist these response messages in your business components, as the data in these messages contain a validity period and the data shouldn't be used beyond this expiration time. The general practice is to store PII data in the memory securely and whenever exploration happens, the business components should send a new request message seeking a valid set of data.

Provide Transparency

Generally, it is believed that a business should be transparent to their customers and authorities as much as possible, but there are no clear guidelines to decide the measure of transparency. When it comes to PII data, that is not the case as a principal business should be 100% transparent to customers about what PII data is stored by them, storage duration of this data, and the exact purpose of storing this data for the specified period of time. During the system design phase, these aspects need to be given the same priority as business features. Even though this seems like a very simple matter, this requires a major shift in the strategic thinking of the people in various positions in an organization’s hierarchy. Taking an oversimplified example, if your application captures customer profile data, you need to design and provide views for customers to check this data and also facilitate the modification or deletion of this data whenever required.

Another important aspect is the use of visual aids to notify and communicate about an ongoing process that involves PII data processing. For instance, in a mobile application, displaying the standard location icon whenever the app utilizes location data or displaying a standard Bluetooth icon whenever an application communicates with another device over Bluetooth helps users to understand what kind of PII is being accessed by the particular application.

Focus on Consent Management

It used to be considered as a best practice to obtain consent from a user whenever business organizations capture and process PII data. However, with emerging privacy regulations, this became a rule mandated by privacy laws. As such, it’s no longer a nice to have feature but a very important functional feature. In fact, there is an emerging market for software products are solely designed to manage consent.

When it comes to system design, you have multiple options to select from. One approach is to deploy a centralized consent management system which acts as the consent repository and access point for end users to view and modify their own consent. This provides a number of advantages in terms of maintenance, ease of use, and audits but can be costly when integrating the consent management system with other business components. However, there are some on-going attempts to standardize consent management such as Kantara Consent Receipt specification and it’s possible to expect a reduction of integration costs in the future.

The other option is to consider consent management as a part of the business use case and implement within each of the business components. This may provide great user experience (UX) but for the flip side, this can lead maintenance overhead in the long run. In conclusion, it’s better to carry out a thorough analysis in terms of business expectations in order to find the right option for your organization.

When designing and developing consent management components or evaluating a consent management product, you need to focus on several aspects. Some of the most important aspects include:

1. Consent capturing methods - whether it provides user interfaces and/or REST full APIs.
2. The customizability of consent capturing interfaces - what is the underlying technology stack and the ease with which you can make customizations according to organizational policies and privacy regulations.
3. Supported consent storage options and available security mechanisms.
4. Available facility for consent owners to review, modify, and revoke already given consent.
5. The ease with which you can integrate the solution with 3rd party applications and features such as SDKs and agents.
6. Portability of consent data such as export consent - both as human-readable formats such as PDF and text and machine-readable formats such as JSON and XML.

Give the Customer Control of Personal Data

PII data fundamentally belongs to each individual and they should be in control of their data unless there are exceptional circumstances. This fundamental right needs to be reflected in your system design. Consumer rights vary from one privacy regulation to another but there is an overlap into a great extent. For example, let’s compare consumer rights defined under the CCPA and the GDPR.

Consumer rights under the CCPA

1. The right to know what personal information is being collected, stored, and their sources.
2. The right to know the purpose of collecting and storing personal information.
3. The right to know if the personal information is being sold or disclosed, if so to whom.
4. The right to object to the sale of personal information.
5. The right to access personal information stored.
6. The right to receive equal service/pricing regardless of the privacy choices.
7. The right to request the removal of personal information.
8. The right of action in case of a breach of personal information.

Consumer rights under the GDPR

1. The right to transparency and modalities on personal data.
2. The right to be informed on personal information collection and processing.
3. The right to access personal information.
4. The right to rectification of personal information.
5. The right to be forgotten.
6. The right to restrict processing of personal information.
7. The right for notification obligation.
8. The right to data portability.
9. The right to object.
10. The right in relation to automated decision making and profiling.

In order for consumers to exercise these consumer rights, a business organization should establish suitable facilities without any additional costs. One possible option is the recruitment of call center agents who help consumers to exercise the above rights over the phone but that this not a scalable and cost-effective solution. Developing or deploying an end user self-care portal is an ideal solution here because consumers can access and modify their PII data themselves conveniently. Nowadays many identity management solutions provide out-of-the-box self-care user portals that can be customized to suit organizational policies.

Strong Authentication Accosting PII

Once PII data stored in a business system, this data will be accessed by two distinct types of users:

1. Employees of the organization when performing business operations.
2. Consumers who access their own data (usually via self-care applications).

The PII data stored in the system should be governed through strong access policies to ensure that only the right set of employees can access the required set of PII data. These policies should include the conditions under which employees can access these data.

Furthermore, it’s an absolutely necessary step to authenticate both employees and consumers when they try to access PII data in a very strong manner. Authentication technologies such as multi-steps and multi-options can be used to build a strong authenticate system, instead of solely relying on simple usernames and passwords which are no longer considered as viable security options. It is possible to use an array of secure options such as hardware and software tokens such as FIDO, Google Authenticator, one time codes via SMS and email, and mobile technologies such as mobile push and GSMA Mobile Connect.

The use of multiple authentication steps can be cumbersome for end users. In such cases, adaptive authentication is an ideal solution as it facilitates to increase or decrease authentication mechanisms after evaluating various risk factors such as the number of attempts, geographical location, network address, user attributes, and message properties.

Conclusion

This article series discusses the opportunities and challenges that are common for any enterprise that deals with individuals, especially privacy concerns. Instead of considering support for each privacy regulation as an orthogonal effort which greatly effects on cost and time, it is possible to view these concerns in a holistic manner by applying PbD principles which result in time and cost optimization, whilst supporting each privacy regulation.

To learn more about WSO2 Identity and Access Management, click here.