QSAs get asked a lot of “what ifs”.
- If I do ‘A’, will that result in ‘B’?
- What if I do ‘C’, will that accomplish ‘D’?
- If I do ‘E’, will that cause ‘F’?
Where this really hits hard is when an organization is trying to reduce scope in their cardholder data environment (CDE). Another area where this becomes problematic is when organizations are re-architecting their networks and want to take into account PCI or any other regulatory or security requirements. Nine times out of ten, the client wants a QSA to review the new network architecture and “bless it” as PCI compliant. We can discuss scope reduction strategies all day long but, until they are implemented and physically exist, they are all just a theory. And as I like to famously say, “In theory, theory works.”
I know this frustrates organizations, but the essence of PCI compliance is validation. A QSA can review proposed network architectures and state that they “appear” that they will be PCI compliant, but the proof is in the implementation. It is only when the organization can provide all of the configurations and penetration testing results for review that a QSA can then determine the PCI compliance of a network and the related devices.
So the next time you are asking your QSA a hypothetical question, do not get all wound up when the QSA responds with what appears to be a lame, “weasel worded” sounding answer. Until you provide concrete evidence, it is all just words, pretty pictures and a thought exercise.
PCI Guru 
We do this by bringing in an outside consultant, not the QSA for PCI, for the benefit of their experience and where they see the strengths and weaknesses. Only then will be take it to the QSA and we’ll provide the third-party review. We believe that one of the great weaknesses of PCI is allowing the same QSA to design and/or implement controls and then get to sign off on them.
Where that process makes a difference in the real world is when some business unit decides they need an exemption for convenience or the techs and developers don’t want to do it because “It’s too hard”. Rarely does the consultant see something the in-house people security don’t but the presence of a paid-for report saying otherwise can go a long way to doing it right the first time, particularly when a real-world example of a breach is included in the consultant’s report.