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 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, to date, there has not been 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?
It started with the tech. Many PCI projects have fallen prey to the “kid in a sweet shop” phase of technology planning, resulting in a lot of expensive kit that cannot/will not solve the problem, an over-large scope and a project that has cost a lot and is going nowhere.
The answer – in short – is to 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.
With version 3.0 of PCI DSS set to be published on 7 November, here are seven reasons why PCI projects get stuck and how to unstick them.
It is time to reappraiseTechnology 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 wrongThe project took a false step from the start – whether the scope was wrong, or you should have tokenised, or should not have tokenised, or the approach just does not fit the business. Do not 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 will not come on boardIn all fairness, PCI projects often engage the business pretty well, but it can be the case that the business is either not interested or is actively obstructive (changing the way that a business receives money can be emotive). Stop. Get business buy-in. Move on.
The immovable object problem PCI projects often stall because of one area that just cannot be brought to compliance.
This might be rather large – for example, shops, all legacy data – or it might be more modest, such as 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 roll-out) 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.
One size does not have to fit allToo 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 foreverThere 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 to 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 (for example, a store refresh in two years’ time).
Compliance lasted a dayWe were compliant, and now we are not. Either through self-delusion or a monumental effort that simply cannot be maintained, compliance has been attained, but proved to be a fleeting thing. See all of the strategies above.
The changes in PCI DSS 3.0, set for publication on 7 November, mean that everyone who is compliant, or working towards compliance, needs to have an awareness of the changes to plan future compliance.
Impact will be very environment dependent.
For example, physical requirements around point of sale (POS) device security will have a reasonable effect on retailers, but absolutely none on pure e-commerce 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.0.
So PCI DSS version 3 is a significant update and merits some early attention.
While merchants and service providers can still comply with 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 is CEO at information assurance and security firm CNS Group.
Register now to receive ComputerWeekly.com IT-related news, guides and more, delivered to your inbox.
By submitting you agree to receive email from TechTarget and its partners.
If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Related content from ComputerWeekly.com
This was first published in October 2013