I had a question this week regarding v3.2 of SAQ A that pointed out there have been some changes to that SAQ that people may have not noticed given the larger issues with the changes to the PCI DSS. As a reminder, SAQ A is the least amount of PCI requirements any in-scope organization can comply.
Those added requirements to SAQ A are:
- 2.1(a) – Are vendor-supplied defaults always changed before installing a system on the network?
- 2.1(b) – Are unnecessary default accounts removed or disabled before installing a system on the network?
- 8.1.1 – Are all users assigned a unique ID before allowing them to access system components or cardholder data?
- 8.1.3 – Is access for any terminated users immediately deactivated or removed?
- 8.2 – In addition to assigning a unique ID, is one or more of the following methods employed to authenticate all users?
- 8.2.3(a) – Are user password parameters configured to require passwords/passphrases meet the following?
- 8.5 – Are group, shared, or generic accounts, passwords, or other authentication methods prohibited
- 12.10.1(a) – Has an incident response plan been created to be implemented in the event of system breach?
Even when a merchant outsources all of their card processing, these are controls that can still apply because in a lot of cases, a merchant is responsible for setup, management and maintenance of their outsourced payment processes and applications.
In addition, merchant employees will also interact with an outsourced payment system to handle chargebacks and disputes. Those user accounts used by the outsourced environment will normally be managed by someone at the merchant, not necessarily the service provider.
In regards to incident response, the merchant will be involved with incident response even when they have totally outsourced their payment environment. The merchant will work with their outsourcer to work through an incident and those responsibilities of the merchant need to be documented.
As a result, the addition of these controls should not be a surprise to anyone.
PCI Guru 
Are ASV scans required for SAQ A
SAQ A does not have any requirements from section 11, so no, ASV scans are not required. Those would be covered by your third party outsourcer and their annual AOC you should have in your files.
There appears to be a scoping issue with the addition of 2.1. Given the wording the of the question – this control would have to apply to every system on the same network as the Merchant’s system webpage hosting the redirect/iFrame page. Is that the intent? If this was taken literally – from a practical standpoint – Network controls would have to be applied around the merchants web server to limit the scope of checking the systems 2.1 would apply to…
SAQ A assumes that everything related to processing, storing or transmitting SAD/CHD is outsourced to third parties and there is nothing in-scope other than possibly a Web server that does a redirect/iFrame. Under that scenario, even the Web server has limited scope and never comes into contact with SAD/CHD. As a result, the only scope is that Web server if it exists.
Thanks for the response! That is the issue I’m referring to as far as the the merchants web server with the redirect/iFrame which I believe is a very common scenario as company’s try to reduce their PCI scope. That would pull all of the systems on the merchants web server into scope for requirement 2.1.
If the Web server is the only system on that network segment, then it would be the only system in-scope for PCI compliance.
Thanks for the quick response! Yes, that was the point I was trying to make. In many cases I believe the merchants web server will not be on an isolated network segment – which could bring requirement 2.1 into scope for all of those systems on the same network (bringing potential gray area around network segmentation/firewalling). I believe this brings unintended scope creep with this addition to SAQ A.
Yes, there will be a larger PCI scope if other servers are in the same network segment.
Hi,
I wished that all our in-scope systems and processes are SAQ A. However, I observed that a SAQ A process (on the part of the merchant) is tricky. This is because the Service Provider said that although they provide the platform for the online form/shopping cart they are not involved in any way in the processing, storing and transmission of card data because they pass it to their partner payment gateway. Therefore, they do NOT need to be PCI compliant. Is this claim from a sevice provider true and correct?
Thanks,
raul
Service providers are service providers when it comes to PCI whether they actually touch data or not. See my post on the subject, Get Over It, You Are A Service Provider
Me and my QSA colleagues are having a debate regarding what the new SAQ A requirements regarding authentication and accounts apply to. Do they apply to:
* The Merchant’s web server (doing the redirect)?
* Any access the Merchant has to the payment processor’s systems?
The May 2016 Assessor Newsletter seems to incicate that they apply to the Merchant’s web server, but this seems like such a huge change to the SAQ A scope, it makes me unsure if that’s really what the council means.
What do you think?
You and your friends are correct. They apply to the merchant’s Web server that does the redirect or invokes the iFrame. The reason for the change is that the Council and the card brands are finally realizing what the rest of the InfoSec community knew which was that those Web servers are part of the payment chain and need better protection. It is only a matter of time before those same Web servers will need to be ASV scanned as well.
Where did you see that the webserver is in scope in case of an iFrame? I didn’t see any change there ! The SAQ A-EP does apply in case of a redirect but not iFrame.
Both the iFrame and redirect are covered by SAQ A. The management of users applies not only to the outsourced Web site, but also to the merchant’s Web site doing the redirect or the iFrame.
I can’t say I disagree with the bare minimum reqs and intention of PCI-SSC. I would have also included the Integrity checking controls in section 11. Since SAQ A will often be used in e-commerce solutions having outsourced the storage, transmission and/or processing to a PCI compliant PSP using an iframe or re-direction integration… It would be of high value to ensure the page serving the redirect or iframe is not tampered with. I always recommend this to clients even if it isn’t a PCI requirement.
On another note, since SAQ A is supposed to be the SAQ for when you do not have a CDE on site, against what does an organization apply the new controls? (i.e. If the org has a flat network, does it only apply them to e-commerce systems or every system?…) Curious to see how it will be interpreted in coming months/years.