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 
http://itrevolution.com/pci-scoping-toolkit/ – this link does not work anymore, may be needs new source.
It was taken down when the PCI SSC issued their Scoping Information Supplement. I uploaded it to a page here. https://pciguru.wordpress.com/open-pci-scoping-toolkit/
https://itrevolution.com/open-pci-scoping-toolkit/
It is also available here https://pciguru.wordpress.com/open-pci-scoping-toolkit/
Thank you for this article. Do applications which reside on in-scope servers but do not touch CHD need to be compliant? Let’s say there is a pdf reader on a database server that which is in scope. Does the pdf reader need latest patches, logging, access control?
Thanks
Applications that are on an in-scope server need to be assessed because they are “connected to” objects, i.e., guilt by association. QSAs encounter this a lot on application layer servers where a host of applications exist. Some are in scope, but some are not. However they all need to be assessed because they are co-mingled on the same server.
Hi! Thanks for the great post.
One question to clarify – e.g. you have a workstation within your PCI scope, with browser installed (Chrome or such, doesn’t matter). If you try to open some web page and use its responses for further processing (e.g. site helps to calculate the total payment sum) within CDE – does this site become part of PCI scope?
It also would be great if you post your thoughts regarding system connections via browser and PCI scoping.
See the Open PCI Scoping Toolkit (http://itrevolution.com/pci-scoping-toolkit/) for the best discussion of your question.
Thank you very much for the link.
One item is not clear for me. I’m not sure about the right answer on the following question ‘Can the device initiate a connection’ when one system is a web browser (category 1 since it operates within CDE), and another system is some web site which is hosted somewhere far far away from CDE.
As long as the workstation being used to enter the cardholder data (CHD) has a firewall enabled and the browser session is using HTTPS, then from a PCI DSS perspective, the workstation is in compliance. This is where people’s paranoia kicks in and they start worrying about the other computers potentially infecting the workstation entering CHD. If you are not comfortable with having everything together, then you need to physically segment those workstations entering CHD from the others. However, I would argue that if you have the appropriate hardening standards in place along with anti-virus and your network is secure and you rarely have infections, I would not be concerned with having everything on the same segment.
Thanks. Yes, that’s a paranoia we’re trying to deal with 🙂
Toolkit works perfect, but still this tricky moment – keyboard of any device puts this device inside PCI scope – is still open.
Another example. What makes my personal computer or my workstation in the office not part of PCI scope of some bank if I do online payments at their web-site? It’s clear that this bank never included my workstation or any personal device in their PCI scope.
The reason your personal PC, smartphone, etc. are not in scope is that PCI ends at the merchant’s/service provider’s/bank’s point of demarcation. Amazon is not responsible for the security of your PC when you order from them. Just as your bank is not responsible for your PC’s security when you do online banking. However, when you are doing order processing on a PC operated by your organization, that is your responsibility and therefore it is in scope for PCI compliance.
hi, nice write up. However to define the CHD, should be first make card holder data diagram to know where all its flowing in case we have network segmentation and then on the basis of it scoping should be defined? If we need to detailed out the steps while doing scoping (to start a project) on a very broad level, what they would be?
also If the application is PA-DSS certified, do we still need to undergo PCI assessment for all the requirements related to software development & application security or reference to PA DSS will do?
First, the easier question of the two. When an application is PA-DSS validated, requirements in section 6 related to application development have already been assessed. Application development related requirements in section 6 are only for applications that are NOT PA-DSS validated. You would not need to document that those requirements are ‘Not Applicable’ for any PA-DSS validated applications.
I think your first question is related to how to determine scope and you are right. An organization needs to know how sensitive authentication data (SAD) and/or cardholder data (CHD) flow through their network and applications to understand what is in scope and why. Network tools such as those from Solar Winds, FireMon and RedSeal can assist organizations in understanding what network segments are in scope for PCI compliance.
Hi,
I am trying to get this clarified further.
Would web application still be in scope if it uses (i.e. directs its clients to a) 3 Party payment Gateway /Hosted Payment page ? e.g. if the web application uses ‘CyberSource Secure Acceptance Web/Mobile’ ? [http://www.cybersource.com/products/payment_security/secure_acceptance_web_mobile/]
If such a hosted payment gateway is considered a ‘CDE’ , the PCI-DSS v3.1 , Page 10 , section ‘Scope of PCI DSS Requirements’ which says ‘the PCI DSS security requirements apply to all system components included in or connected to the cardholder data environment.’ makes the web application still in scope because of ‘connecting to such a CDE’.
So, it is a ‘YES/In scope’ case, eventhough the said web app does NOT ”process, store or transmit CHD’ (and therefore has a very low risk of getting involved in a CHD compromise) but because it ‘connects to a CDE’.
Would someone have a different view on this please?
The key here is how this payment process is invoked. It appears to be a redirect to CyberSource, but their description of process #1 indicates there are fields passed in addition to invocation of their payment page. It is not clear if those fields involve any payment data or not. I do not believe it does based on further descriptions, but you would need to confirm that fact. If the cardholder data entry does not occur until step #2 as I believe, then I would agree that your Web site would qualify as a redirect and would be out of scope. That said, you would still need to comply with the requirements documented in SAQ A for your Web server. You will also need CyberSource’s AOC for this service.
While the aforementioned gets you PCI compliant, it in no way makes your Web server secure. I would highly recommend that you look at SAQ A-EP and follow it’s guidance for ensuring the security of the Web server that invokes the redirect. I would also recommend that you read my post on SAQ A-EP as well (SAQ ).
Hi,
Thank you very much for your clarification and yes, I would definitely take your advice on referring to the ‘SAQ A-EP’ as a guideline to secure the Web server.
Also, regarding your comment ‘….. then I would agree that your Web site would qualify as a redirect and would be out of scope.’ :
I hope what you meant was: ‘…… then I would agree that your Web site would qualify as a redirect and would be in reduced scope and therefore come under the SAQ A ‘ Is that so?
Just to ensure that I am also referring to the same page as you did (literally!) kindly mention if you mentioned #1 & #2 steps you mentioned in your post is from the page ‘http://apps.cybersource.com/library/documentation/dev_guides/Secure_Acceptance_WM/html/wwhelp/wwhimpl/js/html/wwhelp.htm#href=introduction.html#1137418’
Best regards.
Yes, to both your questions. I should have said that your Web site must still comply with the requirements in SAQ A. And yes, both #1 and #2 in the diagram on that Web page.
Great post!
I have a question about server environments, actually.
Let’s say that an ecommerce operator has a PA-DSS certified application.
They accept credit card details on their website and hand that off
to a gateway ala PayPal Pro.
Since they are now handling the credit card information I would
assume that they fall into SAQ-C.
Question is, would they need a dedicated server?
Or could they still be PCI compliant with a Virtual Private
Server or even Split Managed Dedicated server. Obviously
those two options are more realistic for a small mom and pop operator.
Looking forward to your next post!