Utilizing the PCI DSS and NIST Regulations to Prepare for the GDPR

PCI DSS and NIST Regulations: How to Prepare for the GDPR

Data privacy and data security are among the biggest and increasingly complex challenges facing organizations today. Most organizations are attempting to deal with these challenges against a backdrop of international data transfers and data processing while trying to comply with an array of international, national, and regional laws and regulations.

In the Thomson Reuters Cost of Compliance 2017 report, 70 percent of the respondents expect their focus on managing regulatory risk to increase in 2018, with 20 percent expecting the focus to be “significantly more.”  Most organizations will be subject to a host of new or changing privacy requirements this year, such as those regarding the performance of Privacy Impact Assessments (PIAs), maintaining records of personal data processing, and data breach notifications—just to name three.

So, what is the current compliance landscape for data privacy, and how can compliance rationalization assist organizations with meeting their obligations? How do the Payment Card Industry Data Security Standard (PCI DSS), National Institute of Standards and Technology (NIST) regulations, and the General Data Protection Regulation (GDPR) overlap? Are there pitfalls with rationalizing data compliance obligations and industry standards, such as mapping ISO/IEC 27001 standards to PCI DSS v3.2.1 requirements or attempting ISO to NIST mapping?

The Data Privacy Compliance Landscape Surrounding NIST and PCI DSS

Unlike the European Union (EU) and Canada, which have comprehensive privacy laws, the United States has no single, cohesive federal law regarding the collection and processing of personally identifiable information (PII). Rather, organizations in the U.S. are subject to overlapping and sometimes contradictory sets of national and state laws and regulations.

Federal laws in the U.S. that address PII tend to be “sectoral” and address a specific industry, such as the Gramm-Leach-Bliley Act (GBLA) for financial institutions and the Health Insurance Portability and Accountability Act of 1996 (HIPAA) that applies to “covered entities” such as health care providers and health plans.

On top of this, there are literally hundreds of state and territorial privacy and data security laws in the U.S.—California alone has more than 25. Add to this the industry frameworks and self-regulation guidelines such as the Payment Card Industry Data Security Standard (PCI DSS), and the compliance scope for most organizations becomes increasingly burdensome.

Rationalizing Data Protection Obligations for NIST and PCI DSS

On the plus side, as regulators around the globe are bolstering protections for personal data, the differences among privacy regulations is diminishing. As data privacy regulations mature, they impose similar obligations on their subject entities. Additionally, they offer similar protections for data subjects such as notice, consent, purpose limitation, data retention limits, correction, and security. Nonetheless, the cost of compliance can still be quite high. One way to reduce this cost is to identify and rationalize the most effective common compliance controls across an organization’s data security obligations and prioritize their implementation.

A second reason to undertake compliance rationalization is the rapidly approaching enforcement date for the EU GDPR (General Data Protection Regulation) on May 25, 2018. The GDPR is specifically technology neutral. That is, it intentionally lacks specific technological controls to comply with the data protection obligations it creates. There are broad requirements within the GDPR however, such as implementing “data protection by design and default” and incorporating “appropriate technical and organizational measures to ensure a level of security appropriate to the risk.” These measures can likely be satisfied by meeting other compliance obligations your organization may already be subject to, such as PCI DSS and NIST requirements.

Payment Card Industry Data Security Standard (PCI DSS)

Though the PCI DSS is focused on securing payment cardholder data while the stated intent of GDPR is to protect EU residents' personal data, a PCI breach is also a breach of personal data. Consequently, if your organization is PCI DSS compliant, you’re already investing in processes, procedures, and technological controls that will assist in achieving GDPR compliance “by design and default” and as “appropriate to the risk”.

For example, Requirement 3 of the PCI DSS describes guidelines for protecting stored cardholder data by limiting data retention and utilizing data encryption and tokenization. Requirement 4 of the PCI DSS provides controls for protecting cardholder data in transit. Similarly, Article 32(1) of the GDPR requires organizations to implement appropriate technical controls such as the “pseudonymization and encryption of personal data.”

Likewise, Article 32(d) of the GDPR stipulates organizations have “a process for regularly testing, assessing, and evaluating the effectiveness of technical and organizational measures for ensuring the security of the processing”. Compare this with Requirement 11 of the PCI DSS that calls for regularly testing security systems and processes for efficacy.

Though there are more examples, one interesting overlap between the PCI DSS and the GDPR is Requirement 6 of the PCI DSS, “Develop and maintain secure systems and applications.” Requirement 6.3 specifically requires that organizations “incorporate information security throughout the software development life cycle.” If your organization is already working to meet this requirement, you can make a strong argument for also complying with portions of GDPR Article 25, “Data protection by design and by default” and the implementation of “appropriate technical and organizational measures.”

One caveat regarding the PCI DSS is that it only applies to systems that process, store, or transmit cardholder data. Consequently, many organizations will carve out or segment a portion of their network into a cardholder data environment (CDE) for processing PCI data in order to limit their PCI DSS compliance scope. However, because cardholder data is a small subset of the personal data organizations stores or processes, it is unlikely that you can limit the scope of your GDPR compliance with the same technique. Thus, if you utilize a CDE, you may need to extend some PCI controls outside the borders of the CDE to cover personal data if you want to use those PCI DSS solutions for GDPR compliance.

National Institute of Standards and Technology Requirements (NIST)

Though they are written for the federal government, many organizations in the United States look to NIST publications for privacy and security guidance. Like the PCI DSS requirements, there is overlap between NIST requirements and GDPR obligations. The following three documents are particularly applicable:

The first publication, NISTIR 8062, describes a risk-based approach to protecting personal data and describes the relationship between information security and privacy. It also discusses an engineering approach to protecting privacy, something which is particularly relevant to privacy “by design and by default.” FIPS PUB 200 describes general requirements for information security, while 800-53 provides a specific (and lengthy) set of security controls.

Rationalization Pitfalls

Though control rationalization has a number of benefits, there are a couple of pitfalls to be aware of. The first of these is that the ownership of specific obligations and the associated controls can be lost. Most, if not all, data security frameworks advocate clear responsibility for meeting specific compliance requirements. There must be an individual identified within the organization who will sign off on the control attestation, though he or she might not be managing the daily compliance of that control. Once a compliance requirement has been rationalized across multiple control sets, the responsible person must continue to be aware of the underlying risk and whether the implementation of the control has been effective.

A second pitfall in rationalizing compliance requirements is that gap identification and remediation can potentially be more difficult. Gap analysis is an essential component of a compliance program so that any obligations not being addressed can be identified and effective controls put in place. If compliance requirements are rationalized incorrectly or at too high a level, specific variations in laws or regulations can be missed and not addressed. For example, the U.S. definition of PII falls short of the EU definition of personal data, so only protecting data elements defined as PII would leave a gap for meeting obligations under the GDPR.

Don't Protect What You Don't Store

It’s important to keep in mind that organizations and laws are not static. Rationalization of data protection obligations should be an iterative, risk-based activity. Your internal assessment of the data your organization collects should include whether there is an actual need to store sensitive data. You don’t need to protect data you don’t collect—or worry about complying with the associated laws and regulations.

TokenEx can help prepare your organization to meet the constantly evolving data protection regulations, such as the GDPR. The TokenEx data protection platform provides flexible technologies and methodologies to make tokenizing, encrypting, and data vaulting work with any acceptance channel your organization uses.

Topic(s): compliance , data security , PCI DSS , tokenization , pseudonymization , GDPR