Common mistakes when implementing PCI DSS (and how to avoid them)

Compliance with the Payment Card Industry Data Security Standard (PCI DSS) is an essential requirement for any organisation that processes, stores, or transmits payment card data. However, many companies underestimate its complexity and make mistakes that not only delay compliance but also increase the risk of security breaches.

In this article, we review four of the most common mistakes made when implementing PCI DSS and, most importantly, how to avoid them.

Underestimating the Scope of the PCI Environment

Properly defining the scope of the PCI DSS environment is probably the most critical and at the same time, most underestimated step in the entire compliance process. One of the most common mistakes is failing to correctly define the scope of the PCI environment. Many organisations believe that it applies only to systems that process payments (or, worse, only to systems that store cardholder data), but the reality is much broader.

Section 4 – Scope of PCI DSS Requirements of the Payment Card Industry Data Security Standard 4.0.1 document, dated June 2024, states that the scope includes not only systems that process, store, or transmit cardholder data, but also any system that:

• Is connected to the Card Data Environment (CDE)
• Could compromise your security
• Has direct or indirect access to those systems

Furthermore, many organisations fall into the opposite trap: because they don't fully understand the scope, they end up including too much, which unnecessarily increases costs and complexity.

How to prevent it:

First, we need to determine which elements are included in the PCI DSS scope, and we will rely on the standard itself to identify those elements.

Requirements 12.5.2 and 12.5.2.1 detail the elements that fall within the scope and that we must therefore consider when defining it.

Finally, we’ll need to conduct a thorough analysis of the PCI DSS scope, performing any supplementary tasks related to this exercise that we haven’t done before (card data flows, identification of components within the scope, segmentation, etc.). To do so, we can rely on the following public resources provided by the PCI SSC:

• Guidance for PCI DSS Scoping and Network Segmentation
• PCI DSS Scoping and Segmentation Guidance for Modern Network Architectures

Figure 1 – PCI DSS Scoping Categories (Page 11 - Guidance for PCI DSS Scoping and Network Segmentation)

Having an outdated or incomplete inventory of assets

Without a clear inventory of systems, applications, and devices, it is virtually impossible to comply with PCI DSS requirements, since there are many requirements, whose compliance depends on having a complete, robust, and up-to-date inventory (hardening, vulnerability management and patching, segmentation, etc.). Not to mention that having an unreviewed inventory is, in and of itself, a non-compliance of the standard (Testing Procedure 12.5.1.b).

How to prevent it:

To conduct a comprehensive PCI DSS assessment, it is necessary to understand what the PCI SSC defines as System Components. This information is detailed in the standard itself, yet many companies undergoing the PCI DSS implementation process do not pay attention to it.

Section 4 – Scope of PCI DSS Requirements of the Payment Card Industry Data Security Standard 4.0.1 document, dated June 2024, details the scope of PCI DSS, including a comprehensive list of what is considered “System Components,” which includes (with various examples) but is not limited to:

• Systems that store, process, or transmit account data
• Systems that provide security services
• Systems that facilitate segmentation
• Virtualisation components
• Cloud components

This information is very helpful when compiling an asset inventory, but to ensure its long-term sustainability, it is necessary to carry out additional activities such as:

• Maintain a centralized and up-to-date inventory.
• Include hardware, software, and cloud services.
• Periodically review changes to the infrastructure.

Lack of Adequate Network Segmentation

Network segmentation is one of the key pillars for reducing the scope of PCI DSS and protecting cardholder data. However, many organisations do not implement it correctly or believe that basic segmentation is sufficient.

In practice, poor segmentation can cause the entire corporate network to fall within the scope of PCI DSS, exponentially increasing costs, compliance complexity, and the attack surface.

Some of the most common mistakes include:

• Relying solely on logical segmentation without strict firewall rules.
• Failing to adequately restrict traffic between internal networks.
• Allowing broad access “for operational convenience.”
• Failing to verify whether segmentation is working (lack of testing).
• Omitting cloud or hybrid environments from the segmentation strategy.

How to prevent it:

To avoid these problems, it is essential to take a structured approach:

• Clearly define the CDE (Cardholder Data Environment): Identify which systems store, process, or transmit cardholder data, and precisely delineate that environment.

Do not forget components with “unrestricted” connectivity (flat network) to components that store, process, or transmit card data, because they are also considered part of the CDE.

• Isolate the CDE from the rest of the network using firewalls, VLANs, cloud security groups, etc., limiting communications to only what is strictly necessary.
• Apply the “deny by default” principle blocking by default, allowing only explicitly authorized communications.
• Validate segmentation regularly: PCI DSS requires you to demonstrate that segmentation is effective. This involves:
  • Conducting targeted penetration tests to attempt to “break through” the segmentation (PCI DSS v4.0.1 Requirements 11.4.5 and 11.4.6)
  • Reviewing firewall rules periodically (PCI DSS v4.0.1 Requirement 1.2.7)

Believing that compliance is a one-time project

One of the most dangerous (and most common) mistakes is treating PCI DSS compliance as a project with a beginning and an end, rather than as an ongoing process. Many organisations focus their efforts right before an assessment, manage to “pass the test,” and then let their guard down until the next cycle.

There are clear signs of this problem, which you may find familiar:

• Intense last-minute activity before assessments.
• Documentation that is updated only once a year.
• Manual and non-sustainable processes.
• Excessive dependence on external consultants to “catch up.”

This approach not only compromises compliance but also leaves the organisation vulnerable to real threats.

PCI DSS is not designed as a one-time checklist, but rather as a set of controls that must be maintained over time. When compliance is treated as a temporary measure:

• Security controls deteriorate over time.
• Changes to systems or infrastructure are not properly assessed.
• Deviations arise that may go unnoticed for months.
• The organisation enters a reactive rather than a proactive cycle (when something happens or for the next assessment).

In practice, this means that a company may be “compliant” (which is not the same as “secure”) at the time of the formal assessment but may not be secure for the rest of the year.

How to prevent it:

To avoid this error, it is essential to integrate PCI DSS into the organisation's daily operations considering (but not limited to) the following aspects:

• Integrating Security into Business Processes: Compliance should not be a standalone effort by the security team. It should be part of Software development, IT operations, Change management, Human Resources, etc.
• Set up continuous monitoring implementing automated controls whenever possible, monitor logs, access, and configurations on an ongoing basis, etc
• Review and assess on a regular basis (don't wait for the official assessment), conducting internal self-assessments, scheduling quarterly or monthly reviews, identifying deviations before they become problems.
• Managing every change to the infrastructure in a controlled manner can affect compliance by assessing the impact on PCI DSS before implementing changes, documenting relevant modifications, and verifying that controls remain effective.

There are many other tasks that help ensure that PCI DSS compliance and the security of the environment become an ongoing process, but it is not the purpose of this article to detail them all.

Section 5 – Best Practices for Implementing PCI DSS into Business-as-Usual Processes of the Payment Card Industry Data Security Standard 4.0.1 document, dated June 2024 explains how an organisation can implement “business as usual” (BAU) processes as part of its overall security strategy by taking steps to ensure that the security controls established to protect data and the environment continue to be properly applied and function effectively as part of normal business operations.

Properly implementing PCI DSS is not just about complying with a standard, but about protecting your business, your reputation, and your customers’ trust.

Avoiding these common mistakes can make the difference between efficient compliance and a costly, frustrating process. The key is to adopt a proactive, ongoing approach that aligns with security by design.

Is your organisation ready to comply with PCI DSS without making these mistakes? Now is the time to assess it and speak with the experts at Integrity360.