Here a topic that drives a lot of discussion and can, at times, create rifts between an organization and; their ASV, their QSA, their processor, or even the card brands. By definition:
- Anything is considered in scope if it either processes, stores or transmits cardholder data (CHD); and
- CHD, at a minimum, is the cardholder’s name, the primary account number (PAN) and the expiration date. Any additional information from a credit card such as CVV/CVC/CID and track data is also considered CHD, but it may not be stored except during the authorization of a transaction.
One would think such simple definitions would make this all clear. However, there seems to be a lot of interpretation as to what is considered in scope. And it’s all of this interpretation that is causing problems and consternation. So I’m going to make an attempt to clear this up.
First let’s talk about applications because those are typically the easiest to identify as in scope. An in scope application is one that either processes, stores or transmits CHD. Obvious examples of applications that meet this criteria are integrated point of sale, an e-Commerce shopping cart and centralized credit card authorization and settlement. Where it becomes tricky is when it is not clear if the application processes or transmits CHD. Another tricky area is when the application in question is PA-DSS certified. All PA-DSS certification means is that the application, when implemented to the vendor’s documented specifications, processes, stores and/or transmits CHD in accordance with PCI standards. PA-DSS certification does not imply that the implementation of that application meets the PCI DSS requirements. The implementation needs to be assessed to ensure that it was implemented to the vendor’s specifications to maintain its PA-DSS certification. Once deemed to be compliant with the PA-DSS, a QSA can then rely on the PA-DSS certification to cover a number of PCI DSS requirements.
Where I see the most issues with in scope is around the network and servers. So, let’s go back to our definitions. If it processes, stores or transmits CHD, then it is in scope. Servers are in scope if they process, store or transmit CHD such as with database servers and application servers. Pretty straight forward as long as you can identify all of your databases and applications that are in scope. Networks are in scope if they process or transmit CHD. This is where network segmentation becomes important to minimize in scope items. [See my entry on Network Segmentation for a full discussion on that topic.] Where the network in scope issue becomes stickiest is when appropriate segmentation has not been maintained. It is then that all devices on the network end up in scope because oneor more devices on the same network are considered in scope.
External vulnerability scanning and penetration testing also causes problems with a determination of what is in scope. External vulnerability scans and penetration tests are only required when CHD is processed, stored or transmitted over the Internet. Such applications would be any e-Commerce on your organization’s servers and/or networks. If you totally outsource your e-Commerce or do not have e-Commerce, then external scanning by an ASV and conducting penetration tests is not required as there are no in scope applications or devices. However, as a best practice, you should conduct external vulnerability scanning at least annually or whenever you make any significant changes just to make sure your security measures are functioning properly. Internal vulnerability scanning and penetration testing is required at least quarterly or whenever significant changes are made to your internal PCI in scope environment. However, those do not require an ASV to perform.
Hopefully I’ve cleared the air on this simple, yet demanding, topic.
PCI Guru 