An Introduction to Defining PCI Scope

Article PCI DSS
Defining PCI Scope

 

Properly defining the scope of your organization’s cardholder data environment (or CDE) is a primary success factor for achieving PCI compliance. Too narrow of a scope can leave cardholder data at risk for exposure, while an overly broad scope will lead to unnecessary costs and efforts.

So what exactly falls within your organization’s PCI scope? Unfortunately, this question isn’t always so easy to answer. Defining the CDE can be difficult, even for the smallest of organizations, which is why many will partner with a PCI SSC-validated QSA company to perform a comprehensive assessment of the organization’s environment and accurately define the scope.

According to the PCI Data Security Standard, the people, processes, and technology that handle cardholder data are considered in-scope for PCI compliance and, therefore, part of your CDE. All system components included in, or connected to, your CDE are included in the “technology” portion of the above definition. Across your organization, this could include point of sale devices, office workstations, ecommerce web sites, online shopping carts, phoned-in payment transactions, computer labs, kiosks, and more. Any systems connected to the same network segment are also automatically in-scope for PCI compliance because if one of those connected systems are compromised, with no firewall in place to prevent access, they can potentially provide a hacker with an easy path to other system components that are handling cardholder data.

Let’s look at a real-life scenario. A Student Accounts staff member accepts tuition payments by phone, and enters the payment card information into a customized payment application on their desktop computer. This payment application runs on a server that is hosted on campus. In this example, the staff member’s workstation would be in-scope, as would the payment application server, as well as every network device the traffic passes through. A common mistake organizations make is to segment or isolate the payment application server, but leave the employee’s workstation out of scope. If employees are accessing or entering cardholder data on a general purpose workstation, then those systems are in scope!

PCI scope also includes all systems involved in managing the security of other in-scope systems, like authentication servers, key management servers, log management servers, anti-virus management servers, domain controllers, and firewalls. If a system could potentially affect the security of cardholder data it must be included in your scope.

As you can tell, an organization’s PCI scope is very difficult to define and partnering with a QSA company will help you ensure that you are appropriately using your limited resources to secure only those systems that are included in your PCI scope. Before hiring any external resources, there are several things you can do internally to start identifying what systems may be in scope:

  • Complete a current and accurate inventory of all systems and devices used to handle payment card data.
  • Document the cardholder data flow across your organization. Once the data flow is defined, develop a network diagram that documents all of the connected devices – firewalls, routers, switches, terminals, computers, access points, servers, and other network devices and how they are set up. Networks, web applications, point of sales systems, etc. can all operate and communicate differently based on how they are configured and what other systems they have been developed to integrate with, so ensuring you have up-to-date network diagrams is important.
  • Evaluate the business need to handle cardholder data. If there are areas that are accepting one or two payments a year, is it really necessary to continue that practice? Can business practices be changed in certain areas so that payments are customer driven versus being handled by employees? Can all card-not-present transactions be handled via an online solution? The more you can reduce your staff-involved payment card activity, and thereby your PCI scope, the better your organization will be.
  • Isolate/segregate systems and components that are hosting PCI-related applications or information. Network segmentation, although not a requirement for PCI compliance, is the fastest way to reduce the burden of PCI for your entire team. If possible and reasonable, consider re-designing your network infrastructure and moving CDE systems into their own dedicated environment. By properly segmenting the cardholder data environment from the rest of the network, there will be less infrastructure for the IT Team to maintain, and each merchant area may be eligible to complete a shortened Self-Assessment Questionnaire (SAQ). Depending on the level of reduction in PCI scope, the requirements for logging, quarterly scanning, and penetration testing may be answerable as “Not Applicable” for that environment.
  • Scan your entire network to confirm that cardholder data is not stored anywhere outside of what you are now defining as your CDE.
  • Educate your merchants and staff, and implement procedures that require approval from the PCI Team before any new processes or systems that handle payment card information can be implemented. This is important in order to limit scope creep. You don’t want to put in all of the hard work to define and segment your CDE, only to find out down the road that departments have implemented new technologies that are now putting your wireless network or other systems back in scope.

Reducing the scope of your cardholder data environment is a great way to ensure your overall PCI compliance effort is less resource intensive and less costly. If there is little or no separation between your in scope CDE and non-CDE components, then all 300+ PCI DSS requirements must be applied to ALL of the systems in your network, and no one wants to go down that path.

If you have questions about your organization’s PCI scope and how to determine if you are implementing the correct security controls on connected systems, contact us.

Some additional guidance from our Security Advisor team below:

[Stelly]: It’s important to know what is meant by the term “scope.” It’s not just “what’s in view,” but also “what’s in view up to and including the edge of the lens from which you’re viewing.” The scope includes everything within your cardholder data environment AND the controls (policies, firewalls, segmentation, etc.) that keep your CDE safe.

In the PCI assessments we provide, instances of BYOD (bring your own payment device) and BYOP (bring your own payment practice) are often encountered where staff, with a desire or legitimate need to accept payment cards, bypass administrative policies and/or technical roadblocks to get what they want. When an unsanctioned BYOD/BYOP is discovered, the initial reaction by financial/accounting/IT is usually to issue a strongly-worded cessation order and reprimand, but these occurrences are much more valuable as learning experiences for departmental leaders. Questions worth asking or discussing between members of the PCI Team after a BYOD/BYOP discovery may include: “Was a policy actually violated? Is establishment of a new card payment process or contract relationship prohibited by policy? Is the process for proper establishment unclear? If we have a dedicated CDE network segment, why were [they] able to process payments on the default network? Shouldn’t all the allowances on the CDE network exist as disallowances on all other networks?”

Share

About the Author
Katie Johnson

Katie Johnson

PCIP

Manager, Operations Support

As the manager of Operations Support, Katie leads the team responsible for supporting and delivering CampusGuard services including online training, vulnerability scanning, and the CampusGuard Central® portal. With over 15 years of experience in information security awareness training, Katie is also the Product Lead for CampusGuard’s online training services. As a Senior Customer Relationship Manager for a limited number of customers, Katie assists organizations with their information security and compliance programs and is responsible for coordinating the various teams involved.