It has been a little over 21 years since the Payment Card Industry Data Security Standard (PCI DSS) was rolled out to the world in December 2004. The major payment card brands came together as the PCI Security Standards Council (“SSC”) to unify the different payment security programs across Visa, Mastercard, AMEX, Discover, and JCB International.
Soon after, merchants and service providers established PCI compliance programs to demonstrate their required level of compliance based on transaction volume:
The latest PCI DSS release is v4.0.1, which was released as v4.0 in March 2022 and underwent minor updates to become v4.0.1 in June 2024. The sunsetting of “grandfathered” requirements in v4.0.1 occurred on March 31, 2025.
Through the twenty-plus years since inception, the obvious factors determining an entity’s requirements for PCI compliance – that if you store, process, or transmit account data, even just one credit card number, you must comply with the PCI DSS – have been well communicated and understood across the payments industry. However, the fourth criterion regarding PCI compliance – that services, systems, and functions that can impact the security of account data—even if they do not directly store, process, or transmit cardholder data- fall within PCI DSS scope - is often forgotten or misunderstood.
This article helps you understand how PCI DSS scope extends beyond the cardholder data environment (CDE). It highlights how connected systems and supporting services can impact account data security and why continuous monitoring is essential to maintaining compliance.
The PCI DSS reports define in-scope connected-to systems, security-impacting services, and supporting business functions. Within each PCI reporting template, a description of the payment card business/environment is required for all services and functions that directly store, process, or transmit account data. These are the prime determinates for PCI compliance. However, each reporting template also requires a description of services and functions that could impact the security of account data.
While we cannot cover every conceivable security-impacting service function in this article, here are three examples of business services and functions that fit this description and that should be reviewed no matter how “mature and established” your merchant or service provider PCI compliance program is.
1. Network Services and Related Functions
Technologies involved in supporting the interconnectivity of physical/virtual servers, end user workstations, applications, and databases are a primary threat vector to the compromise of account data. Network security controls (NSCs) like VLANs, ACLs, and routing/switching components managed by the network administrators can be improperly configured or changed without detection, leading to potential lateral movement within an entity’s network and into the CDE. Supporting services like DNS, DHCP, NTP and technologies like VPNs and Wi-Fi can all be compromised and allow an attacker to compromise account data.
Real-world example: Avertium has seen instances where changes to NSCs were not properly communicated in advance of their occurrence. This caused unnecessary temporary outages to payment processes that resulted in customer complaints.
2. Authentication and Identity Management Functions
Proper access control and provisioning using the principle of least privilege are critical to ensuring that out-of-scope systems, components, and users cannot open vectors of attack that could lead to account data compromise. Proper Active Directory and/or Azure AD management coupled with proper user ID/password policies and MFA integrations go a long way to shutting down unauthorized access to in-scope systems and data. Privileged access management and the assurance that only users with a legitimate need to access the CDE can do so is critical.
Real-world example: Avertium has seen many instances where terminated employee user accounts or privileged vendor accounts have been allowed to remain enabled in the CDE. Most often it was due to hesitance from administrators based on pressure from other areas of the business to leave them in place. We haven’t seen compromises as a result, but these organizations were lucky, not necessarily diligent.
3. System Administration and IT Operations
While there are some scenarios where these services and functions are not in scope for an entity’s PCI compliance program (i.e., external scans for a P2PE environment), the maintenance of systems and functions included in the CDE are often configured and their standards are set without account data security in mind. Examples include:
Real-world example: Avertium has encountered situations where unpatched systems caused outages for both payment account database functionality and supporting application interfaces. While payment solution vendors are required to update their applications per the Secure Software Standard, it is up to each organization to ensure that updated configuration requirements and software patches are applied.
For each of the examples above, entities must ensure that critical controls are continuously monitored and improvements are made each time there is a change in scope or critical processes. Given there are service providers that focus directly on those services and functions that both merchants and service providers rely upon for their PCI scopes, that makes the service provider’s state of compliance that much more important to an entity’s overall security posture. Examples include managed network providers, managed SOC or SIEM providers, outsourced IT support/system administration, physical data centers, cloud hosting providers, and software vendors with remote access.
Organizations cannot afford the risk created by completing their three- to four-month annual PCI assessment cycle and simply setting it aside once the report and Attestation of Compliance (AOC) is issued. Protecting the security of account data requires understanding the myriad ways that security can be impacted and the continuous application of a “scope validation and maintenance” mentality.
Avertium’s Governance, Risk, and Compliance solutions turn reactive compliance into a proactive strategy that keeps pace with evolving regulations, best practices, and an ever-shifting threat landscape.
Reduce payment risk and stay PCI DSS–aligned through targeted assessments that uncover gaps, secure cardholder data, and support ongoing compliance. Read the Managed PCI Solution Brief to see how Avertium turns PCI from a checkbox exercise into a proactive security advantage
Related Resource: