How to Reduce the PCI Scope for Easier Compliance

Most businesses have trouble being PCI DSS compliant and specifying PCI Scopes. There are a lot of PCI DSS requirements depending on the size of companies, and often it can take a lot of time and effort to ensure PCI compliance or to complete Self-Assessment Questionnaires (SAQs).

REDUCING PCI SCOPE RESULTING IN LESS EFFORT AND COST

Want to narrow your PCI coverage? Maybe you want to reduce your workload in this way. Or it would be best if you reduced the costs associated with PCI compliance.

In our article, you can find out how to minimize PCI DSS scope and the essential factors you should consider in PCI council guidelines.

What would you do first to make your business PCI compliant? To get started with PCI compliance, you first need to determine your company’s PCI scope.

What is the scope of PCI?

Before discussing how to reduce your PCI scope, we’d better explain what PCI scope is. PCI DSS can be defined as PCI DSS security requirements, the scope of which applies to all system components in or related to the cardholder data environment.

See Also: Scoping and Segmentation for PCI DSS

The cardholder data ecosystem consists of people, processes, and technologies that store, process, or transmit cardholder data or sensitive authentication data.

Your PCI scope includes everything in your company that processes, stores, or transmits cardholder data, and everything associated with it.

Simply put, any system, process, or employee PCI that contains credit card data is within your scope. And it is your responsibility to ensure the security of this card data.

Below is a quick list of system components that are likely to be found in your environment:

• Network devices
• Firewalls
• Servers
• Keys
• Routers
• Security devices
• Applications

If you haven’t determined your PCI scope or have not created your card data flowcharts, you may be quite surprised to see how much credit card data your company is unknowingly storing in random locations.

As a result, cardholder data that individuals, processes, and systems store, transmit or process, and components that may affect their security, are considered to be within the scope of the PCI.

Components covered by the PCI may differ for each company, but we can usually identify components that may be in scope and outside of it in advance. In this way, we can speed up the work of determining the PCI scope by knowing where to focus more.

PCI In-scope systems

The PCI in-scope definition applies to all systems and networks directly involved in the card data environment (CDE). Systems are covered by the PCI store, process, or transmit cardholder data.

See Also: What Are the Ways to Reduce PCI Scope

Also, it should be noted that other components that are in the same network segment with systems that store, process, or transmit cardholder data are within the scope of the PCI. Such components are also part of the CDE, which must meet all relevant PCI DSS requirements to protect cardholder data.

Examples of components that could be considered within the scope of the PCI are:

• Code distribution servers
• Antivirus systems
• Domain Controllers
• Hypervisors with CDE systems
• DNS servers
• Log servers       
• Patch management servers
• Authentication servers

Out of scope PCI systems

Systems that may not be within the scope of the PCI include components that are not within the cardholder data environment (CDE) or that have nothing to do with the CDE. Features that make components out of PCI scope include:

• The system component does not store, process, or transmit card data.
• Not on the same network as components that store, process, or transmit card data.
• It does not depend on any components in the card data environment (CDE).
• It must not meet any criteria to be linked to any component in the card data environment (CDE).

System components will be considered out of scope only if they meet all these requirements stated above.

The main challenge many companies face when determining PCI coverage is deciding whether a component is out of PCI coverage. When determining the PCI scope of an environment and before removing components from the PCI scope, you should evaluate all systems within the PCI scope until you verify that appropriate segmentation controls are in place.

There are segmentation validation controls (PCI DSS Requirement 11.3.4) that help determine whether a system or network segment within the network can be considered out of scope.

With the segmentation validation test, you can decide whether a system or network segment has any access to the CDE. This way, you can more clearly and accurately determine whether the component might be within the scope of the PCI.

See Also: What Are the Effects of Using Active Directory as a Shared Service on PCI Compliance?

After the segmentation test, you can determine which connection the components have to any network and also decide whether the component can use a connected system to access the CDE. If there is no requirement, you can narrow your PCI scope by taking the component to a network that does not have access to CDE.

It should also be noted that systems outside of the PCI scope, even if protected, may pose a risk to your company and possibly the CDE. It is recommended that you also consider and follow security best practices for devices, applications, and networks outside of all PCI scope.

Sample systems accepted outside the scope of PCI are as follows:

• Internet
• Systems not dependent on CDE or CDE components
• Systems that are connected to systems in the connected group but cannot use this link to access the CDE.

How can you determine your company’s PCI DSS scope?

The first step to determining PCI coverage is to identify all the places and ways your company can contact cardholder data.

Here are some questions you can ask yourself to locate cardholder data:

• How do you save cardholder data?
• Where do you keep cardholder data?
• How do you manage the systems?
• How do you log on to the systems?
• How do you make system backups?
• How do you log in to receive reports?
• How are passwords reset?

Sometimes you may think that some of your processes may not be included in your PCI scope. For example, employees can receive card numbers by phone or receive e-mails with card details. Besides, there are procedures in which card data can be obtained manually in cases such as power failure.

It is crucial that you also keep track of paper traces to make sure all card data is safe in your business. The PCI also covers cardholder data and related processes that may be on paper.

See Also: How to Define PCI DSS Scope

Before you can determine the scope of the PCI, you need to consider everything in your environment. Even if you think it is outside of the PCI scope, temporary files, log files, or even backups of unencrypted data may contain cardholder data without your knowledge. Check your devices and regularly scan the devices to identify situations like these and make sure card data is not stored.

Once you have the devices covered by the PCI, identify all components that can communicate with them. If you have a server that processes data from the cardholder, consider what else will be connected to that server. Who do you allow access to your card data, and how do you transfer card data?

Always worry and question how employees communicate with card details. Are there any procedures other than the specified procedures? Will they keep the card details on their desk? Is credit card data collected by phone? Such processes need to be remembered and controlled at all times.

Then understand how cardholder data flows.

First, consider your entire environment as a black box. You don’t need to worry about what’s in the box right now. Just worry about the entry and exit points of the cardholder data.

The second question you should ask is where and how do you send cardholder data in your environment? Streams that you are not aware of may still be in the scope of the PCI. It would be best if you did this query every three months or at least once a year.

Examples of entry points for cardholder data into your environment are:

• POS systems
• Mobile POS systems
• E-commerce website
• Mail order/telephone order systems
• Virtual terminals
• Outsourced processes

Examples of places where cardholder data you send after payment is transmitted are:

• Processor
• Back-party server of the organization
• Backup server
• Third Parties that store or process their Primary Account Number (PAN)
• Outsourced management of your systems or infrastructures

Now that you know more or less what is in the black box, you can understand what is going on in it by asking the following questions:

• Is your website hosted at your location or through a third party?
• Does your system perform account transactions at the end of the day?
• How is your terminal connected?
• Card data going to a storage database?

You should carefully examine and take a good look at the devices and systems and everything related to them that touch the streams. This process will help you understand which systems are covered by the PCI.

How to create a flowchart for card data?

PCI DSS requirement 1.1.3 requires merchants to create a valid cardholder data flow chart. Once you become aware of your card data flows and know which systems they are communicating with, you can easily create a card data flow diagram that shows how card data moves in your environment.

See Also: PCI DSS Network and Data Flow Diagrams

Remember, you should create a separate card flow chart for each card data flow in your organization.

First, examine your network topology and network diagram and determine how it fits into your board flow diagram.

• How is your network set up?
• Is there a firewall in your card processing environment?
• Is your network segmented internally?
• Do you have a multi-interface firewall in your environment?
• Are you using more than one firewall?

To create the card data flow chart, you must also understand the fundamental components that make up your network and the applications associated with these components. Only then can you embed card flows into systems and diagrams in the networked environment and understand which systems are storing, processing, or transmitting cardholder data.

You can create your flow chart by determining which components the card data, whose entry and exit points have determined in your environment, progress step by step after the first entry point.

Important note on storage of primary account numbers (PAN)

When you electronically store the Primary Account Numbers of credit cards, you are automatically eligible for PCI SAQ D.

Storage of PAN data is the most significant factor in increasing your coverage. The biggest problem here is that many merchants do not know and are unaware that they store unencrypted PAN data.

For various organizations, the act of storing primary account numbers (PANs) has already had a significant impact on network security. Over the years, major data breaches have been known to occur due to companies choosing to store PANs for fast access on their servers.

For example, finance departments often send bank statements with full cardholder numbers. Likewise, financial departments receive an e-mail notification from time to time in the reimbursement processes and, since they have data protection requirements, they print this sensitive information and store it in a hard copy.

The thing is, as you develop your environment, it is essential to ask both organizations and departments how they get information from the cardholder and then determine what precisely this means for your card flow.

Only after you know this information you can create the necessary processes to protect cardholder data securely.

How Can You Eliminate PANs in Your Environment?

To avoid getting in the dark about your PAN storage, be sure to ask your manufacturer exactly how your POS system works. Does your POS system store cardholder data? Does the cardholder write his information to a database and keep transaction records of processing refunds easily?

See Also: How can you make unreadable stored PAN information?

It is always best to use a card data discovery tool to identify cardholder data. Card data discovery and scanning tools help you identify PANs, processes, and flows that are not within your knowledge. As you discover unfamiliar processes, you can start evaluating what you need to do to improve the process or incorporate it into your environment’s usual systems.

Don’t store PANs if you don’t need them.

If you don’t have any need to keep PANs, it would be better not to keep them! Merchants that store PAN data are only suitable for SAQ D, and SAQ D, which certainly has the most requirements, will not reduce your scope and increase your workload.

If you store PAN data, you must do the following:

• File integrity monitoring (FIM) systems
• Intrusion detection or intrusion prevention (IDS / IPS) systems
• An annual penetration test (internal and external)
• Physical security measures for systems that store sensitive data
• The firewall
• Change control
• Internal and external vulnerability scans

Perhaps you think that storing PAN data will make your life easier. Maybe you are processing a lot of returns. Keeping customer credit cards for recurring purchases provides a variety of convenience. Storing card data may seem like the right decision at first glance because it can increase your income by making it easier for you and your customers. However, the downside is that you hide the PAN because, in this case, your responsibilities increase considerably.

See Also: How do I Protect the Stored Payment Cardholder Data?

If you need to store PAN data, it would be better to consider an alternative method first. Can your bank or provider store card numbers for you and then give you access for refunds via a portal? Can you have your entire payment page done by a third-party service provider? In such cases, you deal with significantly fewer requirements as your PCI scope shrinks, making you SAQ A eligible.

In short, unless you need a convincing job to store PAN data, don’t store it!

Make sure you are compatible with PCI

PCI also requires compatibility for PCI-related secondary systems such as log servers and systems outside the traditional card data environment, such as DNS. Keep in mind these systems and PCI changes as you narrow your scope and comply with PCI DSS.

Outsource PCI functions

Outsourcing is a great way to reduce PCI scope when adequately organized. Service providers can handle some of your more demanding PCI requirements, such as firewall management, log collection, and monitoring, or hosting systems. If you do not need to employ staff to run outsourced equipment, you may want to consider outsourcing by freeing internal resources.

While it may not apply to some businesses, it may be more comfortable if a third party can outsource payments and managing card details. Or for example, tokens or payment service providers can be used to ensure that the organization has limited cardholder communication.

Note that if you outsource payment transactions, you will need to make sure that the organization you are outsourcing to is PCI compliant. In the event of a data breach, you may be held liable if it is shown that you are not sure that the party is legal.

Consider P2PE solutions to reduce PCI Scope.

Another method to reduce PCI coverage is to use point-to-point encryption or P2PE solution. In short, if you correctly implement a P2PE authentication solution and don’t have access to unencrypted data or encryption keys, you may be eligible to receive a P2PE SAQ with only 35 requirements.

Consider tokenization

It eliminates PAN data in your tokenization environment, making it meaningless. In this way, you can store the tokens in your database. In case you apply tokenization, make sure that you do not collect PAN data or keep old PAN data in your environment. You can use card data discovery tools to find PAN data and exchange them for a token.

Once a PAN data is removed from your environment, your risk and PCI coverage will decrease.

Segment your network

Network segmentation is one of the best ways to reduce the scope of card data storage, processing, or transmission systems. Network segmentation is one of the most basic methods of separating systems from the cardholder environment that stores, processes, or transmits cardholder data.

See Also: How is the PCI Network Segmentation Affecting the PCI Scope

Securing all your networks takes more effort and time than just securing those that contain cardholder data. Keeping networks separate from networks that do not handle card data will significantly reduce the effort you spend on PCI compliance. You can do network segmentation by setting up network firewalls and partitioning your cardholder data.

If you use non-segmented flat networks, your entire network will be covered by PCI DSS. The fact that your network is not segmented makes the security of your card data extremely difficult because, in the flat network, your card data environment can communicate with all other components in your network.

By using a firewall to partition networks, you create an interface dedicated to systems that only store, process, and transmit cardholder data. If this interface does not allow traffic from or to other areas, this network is segmented accordingly.

Another way to accurately segment a network without a firewall is to use airspace. Air gaps mean that card data environments are network environments that are entirely independent of other environments. In fact, in this case, the real network devices that control the data infrastructure for the card are entirely separate from your office environment.

Additional tips for determining PCI DSS scope

Once you have determined your company’s PCI scope, you can move on to manage and narrow it. Here are a few tips you can take to reduce the complexity of PCI coverage:

Create a card and network flowchart: These flowcharts allow you to monitor where your card data enters and leaves your environment and which systems are affected by the data flow.

Establish and maintain your policies: Develop policies to handle card data, secure data transfer, and keep the CDE separate from the rest of your business. The established policies and procedures will guide employees on how to maintain a harmonious environment throughout the year.

Reevaluate your environment annually: Conduct and document an annual scoping study. Your PCI coverage may be affected by changes in your environment or threat environment during the year. This review should be done at least annually to ensure that all systems that may affect the protection of cardholder data are adequately addressed.

Remember people: While this article focuses on what technologies should be included in the scope of PCI, keep in mind that the CDE is made up of technologies, processes, and individuals. Identify who is involved in collecting and distributing cardholder information and who uses CDE technologies.

Use limited access: A manager should not have the same access rights as your accountant. Not all employees need access to data about cardholders. You can reduce the number of people dealing with data by restricting access and providing a work hierarchy that can manage card data. Restricting access will increase your overall protection and make PCI compliance a little easier.

Final words to determine your PCI scope

Concerning PCI coverage, protecting your card data should be the top priority. You cannot do this unless you understand how your company manages card data. After all, it is your responsibility to protect cardholder data.

Determining which systems directly or indirectly affect the security of cardholder data in the environment can help you know where PCI DSS controls should be located.

See Also: How Micro Segmentation Can Help You in the PCI Compliance Process?

It is imperative to know your cardholder data entries and exits. Unless you understand the flow of card data, you don’t know what to protect.

Use a card data discovery tool to find where your card data is located. These tools will help you find card data in your network. After determining these, you can determine whether these processes should continue.

Out-of-scope systems do not need PCI requirements. While PCI requirements are best practices for protection, they are not generally mandatory for out-of-range network segments.

Most data breaches can be prevented by applying basic security controls. The security controls specified in the PCI DSS will only help reduce the likelihood of breach when applied to all processes that may affect data security.

The key to protecting your customers’ data is an appropriate PCI DSS scoping application.

Just think and decide, is it worth your company to narrow your PCI scope?

For detailed information, see the PCI SSC information appendix: PCI DSS Scoping and Network Segmentation Guide.