It’s getting to that time of year where we are seeing an influx of PCI business and a constant stream of phone calls and emails from organisations who are only now either hearing about it or have realised that they’ve dropped the ball on it and their compliance deadlines are only a few months away.
The majority of the people we talk with for the first time are shocked to say the least when we explain how tough compliance is going to be if you’re starting from a base of pretty much nothing. (As an aside, this highlights how bad business IT security practices have been all along – across all sectors and all sizes of business). Bottom line is that any business who has had good security practices in place should find PCI DSS compliance relatively not that daunting, as there is not much in the standard itself that is not just plain good ol’ security practice. Why many are under the misconception that the PCI DSS is some radical set of requirements imposed upon poor businesses is still beyond me!
This is what we try to explain to organisations that we talk with for the first time. I acknowledge that for most, the concepts of basic security practices and controls are new to them – that is why it [PCI DSS] is a struggle. If anything, PCI DSS has demonstrated that across the world, very few organisations have ever taken security seriously. It’s rare when see an organisation that blows us away with what they have been doing! Interesting posts here on the PCI Discussion Forum.
So back to the post topic: PCI DSS Compliance Projects – The road to nowhere….
The number 1 biggest issue that we see when it comes to PCI DSS compliance projects, regardless of company size is that they are still seen as IT Security projects – generally delegated to the IT Security Manager to “fix”! And here’s where the games begin, to the detriment of everyone involved – major waste of time, resources and money as every step is a battle. Some of the responses I and others have posted cover much of this so I won’t repeat everything here.
End of the day, if the PCI DSS compliance project in your organisation is run as an IT Security or IT project, it ain’t going to get very far quickly, and in many cases, an organisation will be years down the track and still nowhere near compliance. It’s not that skilled people aren’t able to comprehend what needs to be done – far from it. It’s just that these people don’t have the support of the business and senior business management to get things done. Let me repeat – if the business and senior business management (up to the CEO in some cases) are not involved and actively supporting the project(s), almost EVERY PCI DSS compliance project is going to fail and it’s going to fail over many years – work out the costs of that?! Is that how other major business and IT projects are run? You’d like to think, of course they are not!
So here’s the tip if you’re an IT Security Manager or IT Manager who’s been “dumped” this on your desk. Tell the business:
1. Unless this becomes a “business” project and not an “IT” project, it’s not going to work.
2. Unless the business actively supports this project, with business management being actively involved in all phases of the work, it’s not going to work.
3. Unless the business heeds the advise of the previous 2 points, expect many years of pain, waste of resources, money and staff morale going downhill. Don’t expect to be PCI DSS compliant even then!
At this years AISA Annual Seminar day, we’re going to deliver a different PCI DSS presentation. (Most cover the same old stuff (yawn….). We’re (well Declan) at least is going to look at many of these issues, present case studies and look at areas that many may not be considering. If you’re an AISA member, come along!
Related posts – some relevant, some less so:
http://beastorbuddha.com/category/pci/
One of the better PCI sites that you should consider on your essential reading list is:
http://pcianswers.com/
One last thing to add quickly, spending a lot of money on QSAs and expecting them to magically get you sorted in quick time is also a big mistake. We QSAs can help greatly and do, but end of the day, we’re also hamstrung by the same issues I have raised above BUT, good QSAs though should be able to work with you to help your business understand these critical success factors. Choose your QSAs wisely. It’s not hard to become a QSA organisation but there are very few good ones. Quick Securus Global plug:
http://www.securusglobal.com/services/pcicompliance.html
Do give us a call even if it is just for a chat about your situation.
Anyway, this is not a Securus Global ad, do consider the points raised above as from our experience, this is why after so many years, PCI DSS compliance is still considered a long tunnel with no light at the end of it. PCI DSS has copped a lot of crap but as I said, it’s nothing more than basic good security practice. It’s not perfect and we all know that, but it’s probably the best driver of good security practice globally we’ve ever had! Keen on your thoughts.
“The number 1 biggest issue that we see when it comes to PCI DSS compliance projects, regardless of company size is that they are still seen as IT Security projects – generally delegated to the IT Security Manager to “fix”!”
Maybe because in many cases, they are?
“And here’s where the games begin, to the detriment of everyone involved – major waste of time, resources and money as every step is a battle.”
Why do you think that is? Because the business owners “don’t take security seriously”?
Here’s a thought. Perhaps, just perhaps, the effort required for PCI DSS doesn’t match the risk tolerance of the business owners. Maybe they’re having someone elses’ risk tolerance shoved down their throat? And if that is the case, do you really want to then say to the CEO of a company – as a proxy representative of the PCI, we have more power than you and can force you to do things you would normally never, ever do?
And we wonder why business resent PCI DSS…
Good point Alex.
A client came to me recently and asked “What is in it for us?” It is a simple question with many answers, but when it comes down to it, compliance is compliance, and when you have to comply with a standard to do business it is just another cost of doing that business.
As far as PCI goes there are options, third parties etc but when it comes down to it, PCI doesn’t have to be hard, painful or even too expensive as long as it is managed well from the start.
If however, you are just looking at it now and you have a 3 month timeframe to become compliant, the project is being driven by IT and does not have the complete support of Management- then hard, painful and expensive are not the only words that come to mind.
Hi Alex,
Thanks for coming around and reading. I enjoy your blog.
Your points are from a theoretical perspective, pretty much correct. From our experience though and not just in relation to PCI (which is just a small part of what we do at Securus Global), most organisations do not understand “risk tolerance” – its definition and what it is within their organisation. Rarely do CIOs, let alone CEOs have a clear and even close to accurate picture of where their business risks lie. Most fail the RM 101 part on understanding exactly what their environment is. Without that, they’re lost to begin with in terms of being able to understand that “risk tolerance”.
End of the day though, the payment card brands are setting their rules if you want to play with them. It’s not like PCI DSS should be a surprise anymore to anyone given the years now of warnings to organisations involved. Organisations do have choices to minimise the impact of PCI DSS compliance to them. They can offload all the credit card processing to a third-party, they can segment that part of their environment to minimise the scope of what needs to be in compliance or they can start to adopt some stronger security controls overall.
I’ve found (and once again, not just in relation to PCI) that CEOs and other senior business management will support and be interested in initiatives to improve information security practices within their organisations. Not from fear stories being sold to them but rather logical assessment of where they are at and what their risks potentially are. At this point, our arguments almost join up – but only when all that information/knowledge is available to those people to assess it. Somewhat related post:
http://beastorbuddha.com/2008/08/08/the-cio-sticking-point-time-to-get-them-out-of-the-reporting-line/
When we work with organisations on PCI DSS, our position is no more than advisors and, where engaged, as Auditors. We’d never assume to be able to force anyone to do anything – that is something between the banks, credit card brands and the client themselves.
Regards
DD
I’d take a kind of different tack here DD, though of course I’m not the QSA here.
Alex’s point seems to be that merchants are required to align to the card companies’ risk tolerances, not their own, and that’s a problem of PCI. I’d say that that’s the point of PCI.
An analogous situation would be if someone was holding my money for me. Who’s risk tolerance should they align to? Theirs or mine?
They might say “we have our own risk tolerance here, and you should align to that.” Should I be happy there?
Nope, I’d say “well stuff you and give me my money back.” If they’re holding my money, I’d want them to be as secure as I require. After all, if the money is lost then I lose out, they don’t.
In PCI, the merchants are holding credit card numbers, and the card companies are the ones who are at risk since, after all, they’re going to be the ones handling the fraud. Why would the card companies be happy for the merchants to align to their own risk tolerances?
I think it’s perfectly acceptable for the card companies to say “if you don’t align to our risk tolerances, then don’t collect card data.” Noone’s forcing them to accept card data here.
DD and Matthew:
Thank you for your comments focused around risks, risk tolerance. I am struggling now to provide my management with some concrete risk insights on PCI.
I am the compliance/risk manager for a public company and recently received a question from our CIO: ” Hey Mitch, what’s your risk assessment of PCI”. I stopped for moment and said: 1. It’s required; 2. There are penalties; 3. there is potential brand impairment.
His response was: “I can’t sell that B** S***T to the CEO to get this project off the ground. Tell me what the real tangible risk assessment and costs are to not doing PCI. If I don’t comply, who is going to knock no my door? The External Auditors? No, The PCAOB?, No. Visa or MC, No.
I could really use some help and insight of both the tangible risks and costs of PCI implementation are.
Thanks for your insights!
Regards,
Mitchell S
Mitchell,
I assume you’ve received something from your Acquiring Bank with information on what their expectations are in regards to your organisation being compliant (eg; validation reporting, deadlines etc)?
If that is the case, it’s a big call on the CIOs part to make a decision on behalf of the business – one that could potentially put the business at risk in the event something should happen plus the things you mentioned above. (I would have thought the CEO would be the one to have the authority to make that call). (Acknowledging I don’t know your business).
If the banks and payment card brands enforce this as they state they do/will, non-compliance on your part should be met with fines and continued non-compliance seeing you lose your merchant card processes capabilities. We have seen examples of the latter where the banks have threatened to do this. The merchant generally changes their thoughts on PCI compliance pretty quickly after that.
I hope this helps.
DD