Doing business on the internet usually relies upon being able to take card payments. This, in turn, means being compliant with the PCI/DSS (Payment Card Industry Data Security Standard) rules which ensure that card payments and customer data are properly protected.
In order to implement PCI protection effectively, it’s vital to understand what is within the scope of the PCI rules. Without an understanding of this, you risk overlooking systems or security controls that could raise the risk of a data breach. On the other side of the coin, failure to understand the scope could lead to you overreacting and applying controls to systems that fall outside the PCI/DSS scope.
What is PCI scope?
Under the PCI Security Standards Council, the definition is; “...the identification of people, processes, and technologies that interact with or could otherwise impact the security of the cardholder data (CHD).” [1]
The best way to look at this from a business point of view is to consider the processes by which cardholder data passes through the business. This needs to include not just the ‘front end’ via which payments are taken, but also the back office processes such as reconciling payments with transactions.
In addition to payments, you also need to consider the processes in place for other transactions such as refunds and chargebacks. In short, you need to understand all of the business processes that involve cardholder data in some form. You also need to look at the software and hardware that supports these processes. In total, this is known as the Cardholder Data Environment (CDE).
It may help with this process to create a diagram charting the flow of cardholder data across the business. This should help you to understand the CDE and all of the systems that are a part of it.
We already know that the PCI scope includes all of the systems that handle cardholder data in some form. In IT terms, there are three main components to this.
Hardware and Networks
Hardware and the networks used to connect devices and systems are the first part. These might be wired Ethernet or wireless connections, or even Bluetooth links between devices. However, just because your payment processing systems are on a network doesn’t necessarily mean that the whole network is within PCI’s scope. The rules call for segmentation, this means that systems outside of the CDE shouldn’t be able to communicate with those within it.
This means that, for example, if cardholder data is stored on the company’s main server, then the whole system falls within PCI scope. If it’s stored on another system - such as the payment service provider’s - then only that system would be within the scope.
Applications
The next thing to consider is applications. Those that directly take in cardholder data will always fall within PCI scope. This covers payment gateways, e-commerce websites and management software as well as physical point of sale terminals. Applications must have security standards in place to secure cardholder data. This, in many cases, will mean encryption of data where it’s stored as well as point-to-point encryption for data as it’s transmitted.
Some systems now use an alternative in the form of tokenisation. This converts the card data into a string of characters known as a token, which is useless if intercepted. The token rather than the data is then passed to other systems or the cloud making the transaction more secure.
Software
The third component to consider is software. This covers all of the software used in the processing of transactions. This can be native software running on your servers, in which case the server will be within PCI scope. It can also be cloud software which means it’s the provider’s software that is in scope. However, it’s important that all communications with these cloud systems are carried out in an encrypted or tokenised way.
It’s essential to note here that there may be some systems not directly involved in processing card payments that still fall within the scope of PCI. These include, for example, access control systems that allow access to payment processing applications and software. Other systems that are connected to your payment processing could be within PCI scope too. These include DNS servers that provide online services linked to the CDE. These are a potential attack route so they need to be considered in any overview of the CDE system.
What you should take away from all of this is that identifying what is and isn’t included in the scope of PCI isn’t always easy. Get it wrong and you may end up with card data that isn’t properly protected and that could put both it and the reputation of your business at risk. This is why it’s important to document card data flows in detail to ensure that nothing gets overlooked.
[1]PCI Security Standards
READ MORE: Complete PCI Compliance Guide
