The state of compliance

Verizon published the first global analysis of PCI DSS assessments in the 2010 Verizon PCI Compliance Report (renamed the Payment Security Report). Ten years later, in the 2020 publication of this report, we presented several short-, medium- and long-term trends in PCI DSS compliance, revealing the specific compliance strengths and weaknesses within each industry and geographic region. As before, we pinpointed the best- and worst-performing requirements, with a breakdown ranging from high level— PCI DSS Key Requirements and base controls—down to granular details about which test procedures need the most attention within each industry.

Dataset

For new readers of the PSR, here is a recap of the dataset (refer to page 142 for additional details and our research methodology). The data reported in this section is taken from draft Interim Reports on Compliance (IROCs). These are formal PCI DSS assessment reports that serve as a snapshot of an organization’s PCI DSS state of compliance at a point in time, prior to final assessment. These insightful interim reports capture lapses in controls that can occur as a result of poor compliance management practices or ineffective control design.

Verizon measures compliance performance on three metrics:

• Full compliance
• Control gap
• Use of compensating controls

The state of PCI DSS compliance: Key findings

The trend graphs below present an overview of the compliance performance across all DSS requirements for all regions and industries across the globe, for the six-year period between 2015 and 2020. Overall, PCI DSS compliance improved significantly in 2020. The difference in control performance between 2019 and 2020 is indicated in percentage points (pp). Values are not rounded; therefore, the difference in pp values can be off by a decimal, which should have no impact on the interpretation of the data and decision-making.

Full compliance

The share of organizations achieving 100% PCI DSS compliance at interim validation. This is a reasonable indicator of how well organizations within the dataset managed to sustain compliance by rapidly detecting and correcting controls that fell out of place, and demonstrating 100% compliance when tested prior to their formal annual validation. Nearly all organizations studied passed a previous validation assessment.

The percentage of organizations maintaining full compliance improved by 15.5 pp, from a low 27.9% in 2019 to 43.4% in 2020.

Control gap

The “gap” between the measured state of compliance vs having 100% of required controls in place, when measured during interim compliance validation assessments. In other words, the number of failed controls divided by the total number of controls expected. This is an average figure that gives a measure of how far the assessed organizations were from full compliance. For clarity, a low gap is good and a high gap is bad.

The control gap improved substantially in 2020, from a high 7.7% in 2019 (bad) to a low 4.0% in 2020 (better).

Compensating controls

This percentage indicates how many organizations used one or more compensating controls when a legitimate technical or business constraint prevented them from meeting a requirement explicitly as stated in the DSS. This percentage is not an indication of how many compensating controls were used.

There is a fair degree of variation on the use of compensating controls, from a high of 41.8% in 2017 to a low of 20.6% measured in 2018. In 2020, the use of compensating controls increased by 5.4 pp, with 30.1% of organizations across the globe applying one or more compensating controls to meet the requirements of PCI DSS v3.2.1.

The overall global average full compliance increased by 15.5 percentage points (pp), from a low 27.9% to 43.4% in 2020. Following three years of full compliance in decline (2017 to 2019), organizations focused their attention on improving security management and governance, resulting in significant gains across six of the 12 Key Requirements.

Full compliance improved for each of the 12 Key Requirements. The most significant improvements are Requirement 12 (20.6 pp gain) and Requirements 10 and 6 (both 10.1 pp gains). Requirement 11 remains the least compliant at 60.7%, followed by Requirements 6 and 2—both at 70.5%. Requirement 11 improved by only 8.8% year-over-year.

Similar to the year before (2019), the two most sustainable key requirements remain Requirements 4 and 7—both achieving a high 90.8% in full compliance.

The reason for this increase in full compliance is likely due to the significant increase in data from the APAC region. APAC data contribution went from 9.3% in 2019 to 23% in 2020. The APAC region as a whole achieved 87.0% full compliance in 2019, and this declined slightly by 2 pp to 85.0% in 2020.

The Americas and EMEA regions both saw a substantial increase in full compliance. The Americas region nearly doubled its region-wide average for full compliance.

In addition, there is also a significant increase in the use of compensating controls, with 30.1% of organizations across the globe applying one or more compensating controls—a 5.4 pp increase from 24.7% in 2019. The use of compensating controls increased across six of the 12 PCI DSS Key Requirements.

Compliance performance in 2020 by PCI DSS Key Requirement

The table above presents a high-level snapshot of the state of compliance by measuring PCI DSS Key Requirement compliance performance against the three key metrics: full compliance, control gap and compensating controls.

Full compliance: Here we measure the percentage of organizations that achieved 100% compliance on any particular key requirement, when assessed during their interim compliance validation in 2020. The key requirements are ranked from high to low. The top spot is shared by Requirements 4 and 7 at 90.8%. At the low end, only 60.1% of organizations achieved full compliance on Requirement 11. See pages 130 and 134 for views on Requirement 11.

Control gap: The average control gap across all requirements in the PCI DSS improved substantially, from a high 7.7% in 2019 to a significantly improved 4.0% in 2020. Requirement 11 remains an outlier at 7.4%. Overall, this is a very positive development. Organizations demonstrated that, on average across all key requirements, they could meet the requirements of 96.0% of PCI DSS controls and test procedures, with only 4.0% of controls found not in place during the interim validation assessment.

Compensating controls: The use of compensating controls under Requirements 6 and 8 increased significantly. Requirement 6 remains the key requirement that is most compensated for a second year in a row, followed by Requirement 8. The most significant increase occurred in Control 6.2—Protect components and software from known vulnerabilities (13.9% use), followed by Controls 8.2.4, 8.1.8, and 8.1.6. In general, use of compensating controls is not negative (bad), but it does increase the workload associated with constructing, documenting and validating compensating controls.

Long-term trends

The performance of PCI DSS by key requirement is fairly consistent with marginal long-term variation. This is evident from the long-term (five-year) trends we published on page 68 of the 2020 PSR.

Cream of the crop: The best performing key requirements continue to be Requirement 7 (Restrict access), Requirement 4 (Protect data in transit), Requirement 5 (Protect against malicious software), and Requirement 9 (Control physical access). Over 80% of organizations keep controls from these key requirements in place.

So-so: These are followed by Requirement 3 (Protect stored cardholder data), Requirement 8 (Authenticate access), Requirement 1 (Install and maintain a firewall configuration) and Requirement 2 (Do not use vendor-supplied defaults). These requirements maintain mediocre performance, where in general, more than 70% of organizations maintain those respective controls.

Bad apples: The worst-performing key requirements still are Requirement 11 (Regularly test security systems and processes), Requirement 6 (Develop and maintain secure systems) and Requirement 12 (Security management) where fewer than 70% of organizations maintain those requirements.

Requirement 11 (Regularly test security systems and processes) remains the worst-performing requirement for more than 10 years running but did improve significantly.

The goals, requirements and constraints of PCI DSS Key Requirements

As mentioned on page 30 (Point 4: Goals specific to PCI security) the overall organizational goal of PCI security compliance can be defined as to develop, maintain and continuously improve a mature control environment that offers reasonable assurance for the effective, ongoing protection of payment card data in a consistent, reliable and sustainable manner. To support this overall goal, it’s useful to also define the overall individual goal of each of the 12 PCI DSS Key Requirements within its proper operational context. A too-narrow definition and interpretation of the intended function and outcome of any PCI DSS Key Requirement is counterproductive. It can contribute to the failure to structure supporting project tasks and milestones and to secure the investment needed to pursue the achievement of effective, reliable and sustainable security controls.

Key requirement goal statements

In the following tables, we included a goal statement that attempts to capture the intended overall outcome of each PCI DSS Key Requirement and its contribution toward meeting the overall goal of PCI DSS compliance. Note that these are initial attempts to produce articulated goal statements, and we look forward to improving and refining these goal statements over time with contributions from the broader payment card industry community, and with closer alignment to the changes introduced by PCI DSS v4.0.

The five fundamental elements that should be present in each PCI DSS Key Requirement goal statement are:

1. What and why? This relates to target subject and overall outcomes to be accomplished in context of the overall goal
2. Who and what? This relates to the scope; the entities (stakeholders and participants) and material components involved
3. Will do what? This describes the action – the essential steps and tasks (objectives) to be initiated and completed
4. To what level or degree? This relates to criteria and proficiency needed, and the expected level of performance and achievement
5. In what length of time? This is the timeframe to complete the objectives and the overall goal

The requirements (necessary conditions): Under what conditions can and should the goal be pursued? Here we are not referring to requirements in the context of PCI DSS security requirements (controls), but the critical success factors and conditions necessary to achieve the goal. These factors and conditions are major milestones or intermediary objectives that describe the situation, setting or given material that will need to be in place for completion of the goal— and in many cases they may overlap with requirements as specified in the DSS. We include examples of some of the primary necessary conditions for achieving the goal. Due to space constraints, only some of the primary necessary conditions are listed, and certainly not all the conditions sufficient to achieve the goal. The examples should help you get started on formulating your own complete list.

Strong dependencies and integration: We list the strongly dependent key requirements in a relative order of the strength of the dependencies and need for integration. It’s a short list of strongly dependent key requirements to help support the construction of control systems. There likely is not a single control within the PCI DSS that functions independently of all other controls in the Standard. Every control operates as part of a control system that consists of a collection of controls from various key requirements. It’s essential to design security controls in the context of (1) a control system (dependencies and integrations), (2) influences from the control environment (constraints) and (3) the conditions required to meet the intent (compliance). The control environment consists of all the system components (people, priorities, budget, processes, equipment, rules, laws, policies, standards, culture, etc.) that are related to, interact with and influence the control system.

The effectiveness of all key requirements is in some ways dependent on every other key requirement across the DSS. However, some key requirements have stronger dependencies than others. For example, Key Requirements 11 and 6 are Siamese twins. The effectiveness and performance of controls under both key requirements can directly influence each other. Poor performance or failure of a dependent control will affect the performance or can cause failure in other dependent controls. Likewise, improved integration and optimization in one improves performance in the other. This is why we are advocating a Systems Thinking approach for the goals and requirements of PCI DSS controls.

Objectives: How will progress toward the achievement of the goal be measured? We include considerations for defining relevant short- and long-term objectives as starting points to help decide what should be prioritized and accomplished first in the short term, vs activities that may have a lower priority or require more time to complete. Measuring performance on the completion of objectives is merely one side of the coin. It’s also important to measure the improvement of all related processes and capability maturity. Measure what matters to know how effective, reliable and sustainable each key requirement actually is with the amount of resources assigned to it. Also, such measurement provides visibility on the actual performance and areas of development across the control environment.

Level of performance (maturity): It’s recommended that the goal statement for each key requirement should include the achievement of a designated target maturity capability level. (See page 25 of the 2019 PSR for details.)

The six designated capability maturity levels 0 through 5 are: 0 – Incomplete, 1 – Performed, 2 – Managed, 3 – Defined, 4 – Quantitatively managed and 5 – Optimized. For the effective operation of the control environment, the core processes and capabilities across all key requirements should be at maturity Level 4 – Quantitatively managed or higher. Any capability lower than 4 negatively impacts the effective and sustainable operation of the control environment, and the security of payment card data. Ideally, organizations should target Optimized maturity (Level 5) if not for all, then for at least the most critical processes. This can initially be expensive to achieve for all processes in terms of time and resource allocation, and may require capacity demands that temporarily exceed some security and compliance teams, but can be a very rewarding investment in the long run.

To meet PCI DSS v4.0 compliance for continuous compliance, measuring control effectiveness, and maintaining compliance as a “business as usual” process, organizations should strive to maintain at least Level 4 maturity.

This is where all core processes are quantitatively managed based on an understanding of the common causes of variation inherent in the process, with established performance measurement baselines, and a focus on continually improving process performance (individual competencies and team capabilities) and incremental improvements of all controls and system components across the control environment.

Constraints

Organizational constraints restrict and limit the performance of the requirements and negatively impact the effectiveness and sustainability with which the control environment is operated and the extent to which it can be improved. Without an effective method, elevating and breaking constraints requires a lot of thinking, analysis and decision-making. Refer to the constraints table on page 68, where we categorized the constraints of organizational proficiency in seven categories: 1 – Capacity, 2 – Capability, 3 – Competence, 4 – Commitment, 5 – Communications, 6 – Culture and 7 – Cost.

It is helpful to understand the distinctions. For example: in general, competence refers to underlying ability of an individual to perform a task, while capability generally refers to the power of an organization to collectively deliver objectives.