• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 177
  • Last Modified:



I am with an organization that is starting on the PCI project. We have 3 sites geographically separated that are connected via point to point connections. Only the main site stores the card holder data. The other two sites have workstations that connect to the card holder data environment via encrypted connection. No card holder data is stored at these two sites. We need all 3 sites to be PCI compliant.

Based on the information above, we have a few questions...

1. We understand that the 2 sites that do not store card holder data are in scope, however, do we just need to harden those environments or do we need to go through each PCI requirement and ensure it is met? We understand we have to do that for the main site. We have a firewall on each end of the connection. Each port that is required from the two sites to the main site is document and justified.

We are using the PCI scoping toolkit to define the scope. Our understanding is that category 2 devices do not need the same level of security as category 1 devices. (category 2 devices - workstations at those 2 sites)

2. We understand that risk assessment is requirement for the PCI. Since we are just implementing it, when should we conduct a risk assessment? At the beginning when we define the scope or at some later time?

3 .Should we go through the SAQ to see where we stand (gap analysis) before or after the risk assessment?

Thank you very much for your help!!!
2 Solutions
It's been over six years since I last dealt with PCI compliance so things have probably changed a bit.  In our case though, we only had one site which needed to be in scope and hardened.  So below is from my limited experience and opinion.

Ideally, since the category 2 workstations still access the main site to run the credit card numbers, they should be hardened like category 1 due to having to establish a secure connection through the tunnel.  If those workstations were compromised, then that could subject to a man in the middle attack where the numbers could be sent to an unauthorized location first, and then to the authorizer.

I believe the risk assessment should be done at the time of defining the scope, as well as the self-assessment.  Are you having an independent firm perform the pen test?
btanExec ConsultantCommented:
1. If you can strictly say that cardholder (or credit card) data does not even go to the remote site and its system, then I see that the CDE is contained with the main site.
Thus, a “system component” is part of the cardholder data environment (CDE) if either of the following conditions are met:  

(1) the system component stores, processes, or transmits cardholder data, or
(2) the system component is “connected” to another system component that does satisfy condition (1).
For e.g. remote site only received result of the CD process or request, and there is no sight of CD throughout the remote site and channel. You should still have the security baseline to protect the machine though from the compliance aspect is more organization IT policy compared to PCI DSS compliance.

Otherwise, you will likely still need to harden to the PCI requirement as the endpoint system will still process the cardholder data and connected to the cardholder data environment, or CDE. Even though it does not store persistent CD in the endpoint system, if the latter is infected and not contained, it may spread the infection to the CDE and likewise siphon the CD off the endpoint system. The scene become complicated if it allow remote access thru the endpoint. The security baseline should not be worst off the best practices.

The network segmentation is a must to isolate the CDE (main site) where it regime checks may be far more then your remote site due to the CD existence and risk of exposure. End to End encryption should be understood as data is encrypted and not simply secure channel - pt to pt encryption (VPN). The designated appl/system will decrypted  and prior to that the CD remain encrypted.

To be explicit, the category level is depicted as follows
•Category 1 – System components that process, store or transmit cardholder data or are not isolated or restricted through controlled access from other Category 1 system components.
•Category 2 – System components that have controlled access to a Category 1 system component.
•Category 3 – System components that are isolated from all Category 1 system components.
In a way the remote site should be Cat 2 and main site as the CDE is Cat 1. Logically, the security posture may be more relaxed. Minimally, Cat 2 system components must still be adequately protected to prevent Cat 3 devices from being a valid vector of attack. The access to Cat 2 onsite may be expanded as compared to Cat 1 but the baseline build for the machine should still be able to have the security software like AV, host firewall etc. The difference may be more on the regime checks where Cat 1 may have frequent test/checks with managed policy to validate its restricted interface, account and service on the scoped system.

Also for info
Q9: My business has multiple locations, is each location required to validate PCI compliance?

A: If your business locations process under the same Tax ID, then typically you are only required to validate once annually for all locations. And, submit quarterly passing network scans by an PCI SSC Approved Scanning Vendor (ASV) for each location, if applicable.

 2. The risk assessment should include project and ICT risk and they are conducted once the project proposal gotten budget approval and to start the specific listing of requirement. Those requirement comes also from the risk assessment based on the measure, control and processes needed.

So PCI scoping will be part of your risk assessment cycle so it is really the first thing to be done in spite of the compliance existence. But strictly speaking, the PCI scope is defined first then the activities including risk assessment will move on.

Also risk assessment is not once-off, it is a continuous review e.g. annual or upon major changes to the security design and architecture. As for equipment refresh, it need not warrant a compulsory risk assessment but good to review it if it is key security component as readiness and availability of the service impact the project deliverable too - indirectly the CDE resilience may be impacted if the changes / refresh compromise the security component inadvertently.

3. Yes it is needed. Similarly, the risk assessment and SAQ will have different objective.

Risk  assessment is more on saying that you are already in scope and what measures is adequate to reduce risk and exposure. It is not so much about the compliance checks per se.

SAQ assessment helps to identify the scope control in place and to validate compliance - in short where you stand now and how far to meet the compliance level e.g. identify the baseline requirement before the actual compliance check is done. It can be complicated.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Prepare for an Exciting Career in Cybersecurity

Help prevent cyber-threats and provide solutions to safeguard our global digital economy. Earn your MS in Cybersecurity. WGU’s MSCSIA degree program curriculum features two internationally recognized certifications from the EC-Council at no additional time or cost.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now