Reflecting on challenges of a recent PCI-DSS project for a client and the key learning points for an effective implementation
People team challenges – having a team to champion the project
When we started the PCI project, we were faced with multiple changes in the client’s project manager and so the project was like a car unable to start on a cold morning (for those old enough to remember there were such cars back in the 80s!).
Eventually, by working with the client, the musical chairs stopped and we had a stable project team to champion the PCI-DSS project.
The importance of the scope
By then, so many changes had been made in the systems and people that we were asked to rescope the work. Now, scope in any PCI-DSS project is absolute key. If you start wrongly, you will definitely go down the rabbit hole and never come out.
(Mis)Understanding the process flows
The client described how the credit card data was fed into their system through the credit card terminals connected to their POS systems in their nationwide store network.
Initially, we were quite surprised that credit card data would be flowing back into the retailer’s system so they could do their reconciliation. Our experience suggested that retailers would simply transit credit card information through the credit card terminals to the acquiring bank and then receive back a transaction ID or approval code.
Further enquiries got the same answer and we were assured that the information would be ‘encrypted’ and stored in ‘encrypted’ form.
On the basis of their answers, the client expected to undergo an onerous Self-Assessment Questionnaire, consisting of over 320++ questions!
Managing information
Our team took their word for it, and began the project by asking them to draw out their process flows so we could assist them in scoping their systems and completing an asset inventory (a key part of the PCI-DSS programme) together.
And this was where things got a little messy.
Because they insisted the credit card terminals that were interacting with the cards belonged to the acquiring bank and they had no influence over it, they did not have an asset list.
Also, with a significant number of branches it was difficult to provide an asset list to cover all relevant hardware and software across the portfolio.
The pushback caused the project to once again grind to a halt. Without a scope confirmation, we could not start any PCI implementation for them, in case we over-committed or under-committed on the plan.
Benefits of documenting process flows
The project was being worked out at management level for a long time before it was brought up to the director level, but once it did, things began to move.
We decided to go on the ground to a few of the store locations to really see what was going on.
What we found out surprised everyone:
Credit card information indeed never flowed back into the client’s system!
Getting the terminology right
The so-called ‘encrypted’ credit card information from the bank that was supposedly sent back to the client after the authorization, was in fact, ‘truncated’, not ‘encrypted’.
Apparently, the client had thought these were the same thing.
In PCI speak, encrypt means to protect credit card details by making the information unreadable with a key. The main reason is that there is a need to ‘de-crypt’ the information back again.
Truncation, on the other hand, meant that the card number itself, when sent has already its numbers ‘X’ed out. This is different in a sense that truncated card information is NOT card information because the critical numbers have already been X’ed out, leaving (usually) just first six and last four numbers of the credit card number visible.
Immediately, it was like a light being flipped on.
The team worked hard to optimize the scope by confirming the other flows and observing live transactions take place.
At the end of a 2 day onsite scoping assessment, we concluded that this client was eligible for a much reduced – only around 80 questions – assessment and then by filtering further, we pared down their compliance questions to only 40 reducing the scale of this compliance project by more than 85%.
Key messages
The takeaway here, from our experience would be:
- All PCI-DSS assignments require a stable and strong project team – get the right people, in the right place, with the right focus
- Understand the client’s terminology and descriptions and then check and check again. Ensure that you start from the best position, and not chasing the wrong end of the stick.
- For PCI-DSS merchant compliance it is essential to explore if the client is eligible for any reduction in the scope and don’t just go with the default. The time and cost elements of getting this wrong could be very substantial.
- Nothing beats being onsite and to undertake live walkthroughs of the actual processes. In this case, the earlier the better, so the assignment can be properly scoped. A different set of eyes might be able to unlock the project obstacle – and in our case, it was essential to have the onsite scoping exercise.
Finally, because of these findings, the compliance is now ongoing and finally we are seeing the light at the end of the tunnel.
If you have any queries on your scope or compliance on PCI-DSS, drop us an email at pcidss@pkfmalaysia.com and we will get back to you ASAP.
Leave a Reply