I thought I would write about a recent meeting I had with a client regarding whether or not their proposed point-of-sale (POS) solution was going to be in or out of scope. Obviously, the hope was that it would be out of scope.
I would like to commend this organization for taking the high road to PCI compliance. I wish there were more organizations like them. After slugging through a very ugly PCI compliance process last year with a multitude of compensating controls to get them compliant, senior management set a goal of removing all cardholder data (CHD) from their point-of-sale (POS) systems over the next year and a half. To accomplish this, they are going to implement a tokenization solution on their centralized transaction switch that they are developing in-house. As part of this effort, the company is purchasing a new POS solution that is PABP compliant with the vendor stating that the next version will be PA-DSS compliant. The discussion at my meeting was to determine if the POS solution would be in or out of scope.
Prior to the meeting, the client had provided me with some documentation describing their plans for the POS implementation. I have taken some editorial license to protect the identity of the client, but here is the verbiage that I was provided regarding the configuration of the POS solution.
“The POS PC is connected to a separate credit card terminal by a USB connection. There is a software client running that communicates with their centralized transaction hub that then submits transactions for authentication as well as handling settlement. The only interaction between the PC and the terminal is to pass the amount of the transaction from the PC to the terminal and for the terminal to tell the PC whether or not the transaction was approved or declined.”
On the face of things, the solution appears to keep the POS solution out of scope. However, this is a prime example of why documentation must be complete, clear and accurate. Interpreting the documentation and lacking a detailed network diagram, I assumed that the credit card terminal and the PC had separate network connections.
As Paul Harvey was so famous for saying, “And now for the rest of the story.” It turned out that the documentation had a slight flaw. The person who wrote the majority of the documents had inconsistently used the terms ‘terminal’ and ‘POS’ through out. A common mistake since most people that develop documentation are usually very close to the implementation process and make the assumption that everyone that reads the document has the same background with the topic in question. As a result, it was not clear whether the terminal was the PC or the terminal was the credit card terminal. What the meeting uncovered was that the client software that communicated with the centralized transaction server was in fact running on the PC, not the credit card terminal. This meant that all communications to and from the credit card terminal were routed through the PC to the centralized transaction server. That means that the POS solution is in scope.
The moral of the story is that a good QSA never assumes they know everything about a solution and why they seem to ask many questions about something you would think they would know. The reason is that a good QSA knows that it is your organization’s implementation of the product, not another organization’s implementation and there will be differences. And those differences could mean the difference between in scope and out of scope.
PCI Guru 
0 Responses to “In Scope – Example I”