8 reasons why PCI projects get stuck and how to unstick them
by > , CEO CNS Hut3
(as seen in Computer Weekly)
Payment Card Industry (
PCI) projects, perhaps even more than other compliance driven projects, have a propensity to get 'stuck'. Despite a lot of effort, investment and good intentions, the project never quite gets across the line to compliance. Why is this? And what can be done?
The cynical answer might be because they often can - owing to the huge numbers of companies that need to get to compliance, the attentions of the banks and brands have necessarily been prioritised, meaning that, realistically, to date there has been not too much of a downside in failing to get to compliance for most companies (although this can vary by region, vertical and even individual business).
However, we should accept that compliance will continue to be encouraged by banks and brands – and that there are many other good reasons for complying. So, what causes Stuck PCI Syndrome and what are the potential solutions?
1. It started with the tech… many PCI projects have fallen prey to the kid in a sweetshop phase of technology planning, resulting in a lot of expensive kit that can't/won't solve the problem, an over-large scope and a project that has cost a lot and is going nowhere. Answer - in short - suck it up, write it off (or redeploy) and start again. Write 100 times on the board "Technology is not the only solution" and re-examine the whole compliance strategy as if starting from scratch. And maybe talk to the business this time.
2. It's time to reappraise - technology may not be the only solution, but it can be a powerful component, and the technology has moved on a lot since this whole PCI business started. Many PCI projects, however, have not, and a lot could benefit from taking stock of the technology options now available that can offer a short-cut through a whole lot of issues (e.g. PTPE). Similarly, PSP offerings and other outsourcing options have moved on - it may be time to reappraise the technology/outsourcing mix.
3. The strategy is just plain wrong - the project took a false step from the start. Whether the scope was wrong, or you should have tokenised, or shouldn't have tokenised, or the approach just doesn't fit the business. Don't be afraid to revisit the strategy, as it may be the only way forward. It can be difficult to admit a false start of this nature, especially if it has cost a reasonable amount, but it may be necessary.
4. The business won't come on board - in all fairness, PCI projects often engage the business pretty well, but it can be the case that the business are either not interested or actively obstructive (changing the way that a business receives money can be emotive thing). Stop. Get the business buy in. Move on.
5. The immovable object problem - often PCI projects stall because of one area that just cannot be brought to compliance. This might be rather large - e.g. shops, all legacy data, or it might be more modest - a particular legacy system. Be pragmatic. Can the system or business area be brought to compliance with compensating controls? Are there some more manual workarounds to compliance that might be put in place? Will this problem go away with time (new store rollout) or it is likely to be long term? Must it stop other areas complying? One way or another it is usually possible to either solve this seemingly intractable issue or put it to one side and get on with the project.
6. One size doesn't have to fit all - too often the PCI strategy is carved in stone and then all areas of the business are required to comply using this strategy regardless of fit or practicality. For example, 100% tokenisation may be desired, but may not be achievable in all areas - or all regions. If imposing the same strategy across the board is painful, then look at the exceptions and see if there is an easier way.
7. Nothing is forever - there is a difference between strategy and tactics. There may be some quick, tactical ways to achieve compliance in the short term that allow the grand strategy to be implemented over the medium/long term. That way you have the best of all worlds - the future-proofed, de-risked, long term compliance strategy supported by a short term compliant environment. This can work particularly well where compliance is waiting on another business event (e.g. store refresh in 2 years’ time).
8. Compliance lasted a day - we were compliant, and now we're not. Either through self-delusion or a monumental effort that simply can't be maintained, compliance has been attained, but proved to be a fleeting thing. See all of the strategies above.
The
changes in PCI DSS v3 means that everyone who is compliant, or working towards compliance, needs to have an awareness of the changes in order to plan future compliance. Impact will be very environment dependent; for example, physical requirements around POS device security will have a reasonable impact on retailers, but absolutely none on pure ecommerce businesses. Enhanced testing procedures will probably affect everyone as they are now written through the standard. Penetration testing changes are likely to have a fairly broad effect and finally, clarification in requirement 10 may need some action; more specific log review requirements mean that businesses will need to take action when transitioning to v3.
So version 3 is a significant update and merits some early attention. While merchants and service providers can still comply to v2 during 2014, it is better to plan for the changes now. Stuck PCI projects are ripe for re-examination and now is the time for a reboot.
Kevin Dowd, CEO, CNS Group