Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Make Your Product Compliant with Privacy Laws: A New Framework

public://pictures/shlomi.jpeg
Shlomi Ben-Hur Product Security & Privacy Architect, Micro Focus
 

As public concern over privacy grows, protecting data and complying with a changing regulatory environment can be challenging. Not only are privacy laws proliferating, but measures such as the General Data Protection Regulation (GDPR) in Europe and the California Consumer Privacy Act (CCPA) in the United States frame their requirements in language that might be well understood by lawmakers and lawyers, but less so by members of information security and development teams.

And not complying can be costly. The GDPR states that companies infringing the regulation can be subject to administrative fines of up to Є10 million or, in certain cases, up to 2% of the total worldwide annual turnover of the preceding financial year, whichever is higher (GDPR Article 83.4).

Much of the discussion about privacy compliance focuses on protecting privacy at the organizational level, on activities such as establishing organizational privacy values and policies, identifying legal and regulatory requirements, and understanding organizational risk tolerance. Little information is available about protecting privacy at the product level, where developers live and work.

How can privacy be protected at the product level? A tried-and-true approach to tackling complex security scenarios is to create a framework, a step-by-step process that can comprehensively address a large set of issues.

As a member of Micro Focus Product Security and Privacy Group, I collaborated with our Privacy Counsel to build such a privacy framework that addresses the privacy requirements in measures such as the GDPR and CCPA, as well as incorporating ideas from NIST's privacy framework and the Federal Risk and Authorization Management Program (FedRAMP), which provide a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services for federal contractors.

In building our Product Privacy Framework, we translated the CCPA and GDPR legal language into technical requirements that system engineers and developers could clearly understand and implement throughout their products. Indeed, the benefit of using this framework is the way that the legal requirements are framed in a technical language, separated into the specific R&D roles that need to address them (i.e., developers, system engineers, SaaS operations, etc.). The framework includes a methodology for assessing and tracking the maturity of requirements across 12 key privacy areas that you can apply to any product.

Figure 1 . In Micro Focus' Product Privacy Framework, 90 requirements are gathered under 12 high-level categories, which set the framework's key privacy indicators. Source: Micro Focus. Click to enlarge.

Boiling down the privacy laws

After analyzing the relevant laws, we boiled everything down and chopped it up into digestible chunks for the framework.

First, we grouped the requirements into 12 categories, called "key privacy indicators." They include security and pseudoanonymization, data breach and notification, the right to be forgotten, the right to portability, consent and the right to withdraw, notice, profiling and user behavior, data transfer, data protection impact assessment, supply chain obligations, liabilities, and transparency.

Next, we built a list of 90 technical requirements that engineers could act on, based on 99 GDPR articles and 21 legal provisions from the CCPA.

Then we established a ranking system based on the Capability Maturity Model Integration (CMMI) framework that measures security compliance maturity on a scale from 0 to 4. CMMI is a process measurement and improvement meta-framework that helps organizations measure the effectiveness of their processes and identify how to improve them over time. The US Department of Defense funded and assisted in the development of CMMI. It's currently administered by the CMMI Institute, purchased in 2016 by ISACA.

Figure 2. Here's an example of a technical requirement that engineers could act on, including the maturity level selection. Click to enlarge.

Here are what the scores on the maturity scale mean:

  • A score of 0 means an application is not aware of its current status related to a requirement, or that it doesn't follow a requirement.
  • A 1 means an application doesn't follow a requirement, but a team has performed a gap analysis and a mitigation plan is in development.
  • A 2 means an application follows most of a requirement with some exceptions; exceptions are filed in a form, and the exception form is approved by the product's owners.
  • A 3 means the application follows a requirement.
  • A 4 means the application exceeds requirements by following the requirement in an automated manner.

Finally, we created an Excel file that lays out the technical requirements in a row-and-column format. The rows correspond to the technical requirements. The column labels are "RID," "Requirement," "Type," "Description," "Maturity Level," "Compliance Status," "GDPR Article," "CCPA Requirement," and "Comment."

What a requirement looks like

A typical requirement in the framework might look like this:

The product must identify and present to the end user:

  • All personally identifiable information (PII) data types used in a product
  • All locations/points where PII is collected and stored
  • Justification for PII collection

Since the requirement is related to the product's architecture, its "type" would be architecture. In addition to architecture, there are four other types used by the framework: legal, documentation, implementation, and SaaS operation.

There's also a lengthy description to go along with the requirement that the product must identify all following parameter types for structured data:

  • Types of PII
  • Source of PII, categories of PII, purpose of processing
  • A list of location (pages/fields) in the product where PII data types are collected, and areas in the system where they're stored
  • A list of all data flows, with justification of the PII collection
  • A list of roles that have access to the PII
  • A list of all profiling/big data analytics that is done on the PII of the user
  • Retention period

To clarify matters further, examples may be included with the description. Here's one for the collection of a user's name and email address:

Collected at registration page from data subject, stored in silver DB; the PII is used for communication with the user; visible to system administrator, end user; transferred to integrated marketing system for follow-up; participate in analytics metrics for activities profiling; kept as long as the user is active.

After reviewing the requirement, an organization fills in the columns for compliance status and maturity. The compliance cell in the spreadsheet appears as green if the requirement has been met, yellow if partially met, and red if incomplete. The framework can help you formulate a remediation plan to become fully compliant with its requirements.

The information from the compliance and maturity columns can be used to create useful graphs, too. For example, the compliance column can be used to compare how compliant several products are. The maturity data can be used to create a "spider" chart showing both the current and expected levels of maturity in the 12 key privacy areas identified by the framework.

At the end of the framework implementation process, a template document—called the "Privacy Settings Guide for Administrators and End Users"—can be generated from the framework. Requirements in the document map back to the requirements in the framework.

Getting started takes time, so get started

It can take as long as nine months to get a product privacy framework program up and running, but it takes considerably less time—three months—to maintain the program once it's in gear. Nevertheless, any organization concerned about protecting its products from running afoul of privacy regulators will find the time spent setting up a product privacy framework to be well spent.

Keep learning

Read more articles about: SecurityInformation Management & Governance