by Kevin Dowd
Internet retailing is a relatively young industry, but one that has had to get to grips with transferring retail skills to the online world and managing the technology that goes with that. Consumers are comfortable shopping from their laptops, tablets and even phones. In early 2013, the IMRG Capgemini eRetail Sales Index predicted that £87bn would be spent online this year; a 12% increase on 2012
Consumers have confidence in online shopping because many of the early security questions have been addressed, but the nature of technology means that this is an ongoing project. In order to retain consumer confidence, brands and banks are demanding compliance with payment card industry data security standards (PCI DSS). Unfortunately, despite a lot of effort, investment and good intentions, PCI DSS projects have a tendency to get ‘stuck’ and can struggle to get across the line to compliance.
As a PCI Quality Security Assessor company, we are developing something of a specialty in revitalising stuck projects. Sometimes this manifests itself in a formal review and a statement of ‘stuckness’, more often the symptoms are cancelled meetings, delivery drift, other priorities and a gradual tailing-off of the whole effort, usually because of one or more seemingly intractable problems.
Why do PCI projects fall prey to this so often? 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, I’m not usually given to cynicism (ahem…) and, accepting that compliance is only going to be more and more enthusiastically encouraged by the banks and brands – and that there are many other good reasons for complying – what are the other reasons for Stuck PCI Syndrome and what are the potential solutions?
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.
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.
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, it just isn’t going to work. 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.
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.
The immovable object problem
Often PCI projects stall because of one area that just cannot be brought to compliance. This might be rather large, for example shops, or all legacy data, or it might be more modest, a particular legacy system, but it stops the project in its tracks. 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? It may be that a conversation with the bank is required, but 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.
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.
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 two years’ time).
Talk it over
Try to make contact with others in your industry and find out how they have got to compliance. Various sectors have forums and groups set up just to discuss PCI – join up and find out how others have got over the line. I have yet to see any two businesses – whether in the same sector or not – get to compliance in exactly the same way.
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 coming in PCI DSS version three mean 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 version three.
So version three is a significant update and merits some early attention. Stuck PCI projects are ripe for re-examination and now is the time for a reboot.
Kevin Dowd is chief executive, CNS Group